Swapping, not fragmentation
A ratio below 1.0, which is the more urgent problem and the better-looking number
total.allocated 536870912 fragmentation 0.85
Paste the output of redis-cli MEMORY STATS. The number that matters is rarely the biggest one: a fragmentation ratio below 1.0 is more urgent than a large overhead figure, and it reads like the better number.
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 Analyze. 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 ratio below 1.0, which is the more urgent problem and the better-looking number
total.allocated 536870912 fragmentation 0.85
Above 1.5 the allocator is holding memory the dataset is not using
total.allocated 1073741824 fragmentation 2.10 fragmentation.bytes 400000000
Most of the memory is bookkeeping, which means too many tiny keys
total.allocated 1000000000 overhead.total 700000000 keys.count 5000000 keys.bytes-per-key 60
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
It means resident memory is smaller than allocated, so the process is partly in swap. That is worse than fragmentation, not better.
Instead:Check the operating system and remove the swap pressure.
Defragmentation cannot help a ratio below 1.0, and it costs CPU. It only addresses the case above roughly 1.5.
Instead:Read which side of 1.0 the number is on first.
Memory is released to the allocator but often not to the operating system, so resident size tracks the peak rather than the current total.
Instead:Size for peak.allocated.
Each node reports only its own memory. A shard with a problem does not appear in another shard's numbers.
Instead:Collect it from every node.
MEMORY STATS is thirty-odd fields with no ordering by importance. These are the ones where the obvious reading is the wrong one.
The ratio is resident memory divided by allocated memory. Above 1.0 the allocator is holding extra, which is fragmentation. Below 1.0 the resident set is SMALLER than what Redis allocated, which can only mean part of the process is in swap. On a single-threaded server every swapped page turns a microsecond command into a disk read, and it looks like a lower, healthier number.
Overhead covers the main dictionary, the expires table, client buffers and the replication backlog. Some is unavoidable. When it passes half the allocated total, the instance is mostly bookkeeping, and that shape almost always means a very large number of very small keys rather than anything misconfigured.
Every key costs a dictionary entry, a redis object and the key string, roughly 50 to 100 bytes before any value. When bytes-per-key is under about 100, the overhead is comparable to the data, and grouping those keys into hashes is the single biggest saving available.
Redis releases memory when keys go away, but the allocator does not necessarily return it to the operating system, so resident size stays near the peak and the fragmentation ratio then reports the gap. Size the machine for the peak, not for what MEMORY STATS says right now.
One instance at one moment. On a cluster each node reports only its own memory, so a problem on one shard is invisible in another's output, and a quiet sample says nothing about behaviour under load.