The g versus gb trap
A decimal suffix where the binary one was meant, quantified in bytes
1g 1gb
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.
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.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
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.
A decimal suffix where the binary one was meant, quantified in bytes
1g 1gb
What each redis.conf value actually resolves to
512mb 2gb 100mb 1073741824
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
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.
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.
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.
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.
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.
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.
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.