INFO memory on one Redis instance reports mem_fragmentation_ratio of 1.9, and on another it reports 0.7. Interpret each of those numbers and say what you would do about them.

## What the ratio is made of `INFO memory` reports two independent measurements. `used_memory` is what the memory allocator (jemalloc by default) says it has handed to Redis. `used_memory_rss` is the resident set size the operating system attributes to the process. The ratio is simply RSS divided by used_memory, and it answers: how much physical memory is this process holding per byte Redis thinks it is using? A value in the neighbourhood of 1.0 to 1.5 is unremarkable. There is always some gap: allocators round requests up into size classes, keep per-thread caches, and hold pages they are not currently handing out. ## Reading 1.9 This says roughly 90% overhead. There are two distinct stories. **Allocator fragmentation.** Memory freed by Redis goes back to jemalloc, not to the kernel. If a workload allocated millions of 200-byte values and then deleted most of them, the pages remain resident with live objects scattered across them; no page can be returned because each still holds something. Workloads that churn value sizes across allocator size classes — growing hashes, lists that swing in length, mass expiry followed by different-shaped data — produce this reliably. **Non-data resident overhead.** A snapshot fork causes the kernel to copy pages the parent modifies while the child writes, so RSS climbs during and after persistence work. Big client output buffers, a recent peak now freed, or a large replication backlog also raise RSS relative to the dataset. Redis reports finer figures to separate these: `allocator_frag_ratio` and `allocator_frag_bytes` isolate the allocator's own waste, while `rss_overhead_ratio` captures what is resident beyond the allocator's accounting. If the allocator ratio is near 1.0 while the overall ratio is 1.9, defragmentation will do nothing — the memory is elsewhere. **Remedies, in order of intrusiveness.** Confirm it is allocator fragmentation. Enable active defragmentation (`activedefrag yes`, jemalloc-only), which incrementally relocates objects to free whole pages; gate it with `active-defrag-ignore-bytes` (don't bother below an absolute waste) and `active-defrag-threshold-lower`/`upper` (percentages at which it starts and goes full-throttle), and bound its CPU with the min/max effort settings, because defrag runs on the thread that serves commands. Watch tail latency while it works. If fragmentation is the result of a one-off event rather than a steady pattern, the cheapest fix is a controlled failover to a replica and a restart of the fragmented node, which returns everything to the OS. ## Reading 0.7 A ratio below 1 means the OS has less of the process resident than the allocator has allocated — the missing pages are on disk, swapped out. For a database that expects every access to be a memory access on one thread, this is severe: a single swapped page touched by a command turns a microsecond operation into a millisecond-plus disk read, and because everything is serialized on one thread, every other client waits behind it. Latency graphs go from flat to spiky and throughput craters. The fix is environmental, not a Redis tunable: find out why the host is under memory pressure. Common causes are `maxmemory` set too close to (or above) physical RAM, other processes co-located on the box, a container limit lower than the workload, or a snapshot fork transiently doubling demand. Lower `maxmemory` to leave real headroom, move noisy neighbours off, add RAM, or reduce the dataset. Confirm from the OS side too — the process's swap usage — rather than trusting the ratio alone. ## Caveats worth stating On a nearly empty instance the ratio is noise: baseline process memory swamps a small dataset, so 3.0 on a 20 MB dataset means nothing. Read the ratio together with absolute numbers (`allocator_frag_bytes` in particular) and only act when the wasted bytes matter at your scale. And remember the direction of the arithmetic: memory freed inside Redis lowers `used_memory` immediately, which *raises* the ratio even though nothing got worse — a mass delete or a wave of expiry routinely produces an alarming-looking ratio for a while.