Redis Memory Unit Converter

Paste redis.conf memory values and get the byte count for each, in every unit. Where a value uses a decimal suffix, the difference from the binary one is shown in bytes and percent, because that difference is the single most common mistake in a Redis config.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Convert. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

The g versus gb trap

A decimal suffix where the binary one was meant, quantified in bytes

1g
1gb

Common maxmemory values

What each redis.conf value actually resolves to

512mb
2gb
100mb
1073741824

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Writing `maxmemory 1g` meaning one gibibyte

    A suffix without `b` is decimal. 1g is 1,000,000,000 bytes and 1gb is 1,073,741,824, so the config gives about seven percent less than the capacity plan assumed.

    Instead:Write `1gb`. The symptom otherwise is eviction starting earlier than expected, discovered weeks later.

  2. Setting a container memory limit equal to maxmemory

    maxmemory bounds the dataset as Redis accounts for it. Replication buffers, client output buffers, the AOF rewrite buffer and allocator fragmentation all sit outside it, so resident size is reliably larger.

    Instead:Leave headroom. maxmemory at roughly 60 to 70 percent of the container limit is a common starting point.

  3. Using `maxmemory -1` for unlimited

    That is a parse error, not a synonym for unlimited. Redis refuses to start.

    Instead:`maxmemory 0` means no limit, and is the default on a 64-bit build.

The b is not decoration

redis.conf documents this in a comment block at the top of the file, and almost nobody reads it. The rule is simple and the consequences are not.

The rule

1k is 1000 bytes and 1kb is 1024. 1m is 1000000 and 1mb is 1048576. 1g is 1000000000 and 1gb is 1073741824. Units are case insensitive, so 1GB and 1gb are identical, and a bare number is bytes. The suffix without b is the decimal one, which is the opposite of what most people assume.

Why it matters for maxmemory

maxmemory 1g gives you 73,741,824 bytes less than maxmemory 1gb, about seven percent. Capacity planning is done in binary units because that is what free and top report, so a config written with a decimal suffix reaches its limit sooner than the plan said. The symptom is eviction starting earlier than expected, or OOM errors on a box that looks like it has headroom.

maxmemory 0 is unlimited, not maxmemory -1

Zero means no limit, which on a 64-bit build is the default. A negative value is a parse error rather than a synonym for unlimited. Running with no limit and no eviction policy is how a Redis instance ends up killed by the kernel's OOM killer instead of evicting.

The limit is not the whole process

maxmemory bounds the dataset as Redis accounts for it. Replication buffers, client output buffers, the AOF rewrite buffer and allocator fragmentation all sit outside it, so the resident size of the process is reliably larger than the limit. A container memory limit set equal to maxmemory will be hit.

What this cannot see

It converts units and does not know your dataset. How much memory a given number of keys actually uses depends on the data types, on the encoding thresholds those types fall under, and on allocator rounding, none of which is visible from a config value.