Memory Fragmentation Ratio, Redis

​

At a glance

The ratio of physical memory the operating system has handed Redis (RSS) to the memory Redis believes it is actually using for data. It is a single dimensionless number that tells you how efficiently your dataset is laid out in RAM. A ratio comfortably between 1.0 and 1.5 is healthy: a little overhead from the allocator is normal. Above 1.5 means the OS is holding a lot of memory that Redis cannot pack with data, real RAM you are paying for but not using. Below 1.0 is the dangerous reading: it means Redis’s data no longer fits in physical RAM and part of it has been swapped to disk, which turns sub-millisecond commands into multi-millisecond disk reads.

​

Calculation

mem_fragmentation_ratio = used_memory_rss / used_memory

• used_memory is the total number of bytes Redis’s allocator (jemalloc by default) has allocated for the dataset, structures, and internal buffers, as Redis accounts for them.
• used_memory_rss is the resident set size the operating system reports for the Redis process, the actual physical RAM pages mapped to the process.

• Above 1.0 (normal to high). The allocator requests memory from the OS in pages and arenas. After keys are deleted, the allocator may hold the freed pages rather than returning them to the OS immediately, so RSS stays high while used_memory drops. Mixed value sizes and heavy churn worsen this. A ratio of 1.0 to 1.5 is the expected, healthy range. Sustained above 1.5 means a meaningful chunk of your RAM is held by the OS but unusable for new data.
• Below 1.0 (danger). used_memory exceeds the physical RAM the OS is giving the process, which can only happen when pages have been swapped out to disk. The data Redis thinks it has in memory is partly on the swap device. Every access to a swapped key incurs a disk read, destroying Redis’s latency profile.

​

Worked example

1. This is allocator waste, not swap. The ratio is above 1.0, so nothing is swapped. RSS is 5.27 GB but the live dataset is only 3.10 GB: roughly 2.17 GB of physical RAM is held by jemalloc but not packed with data. The large DEL sweep freed memory inside the allocator’s arenas, but jemalloc has not returned those pages to the OS.
2. There is a clear cause and a clean fix. Fragmentation that follows a big delete is textbook. Redis can defragment online: enabling activedefrag yes (active defragmentation) lets Redis incrementally relocate values to compact memory and release pages back to the OS, without a restart. On many setups the ratio drifts back toward 1.2 to 1.3 over the following hours.
3. Headroom is the real risk to watch. RSS at 5.27 GB against an 8 GB node leaves under 3 GB of OS headroom, and maxmemory is 6 GB. If the dataset grows toward maxmemory while RSS is already inflated, the node could approach physical exhaustion and risk swapping (ratio dropping below 1.0). Pair with Memory Used vs Maxmemory %.

What the 1.70 reading costs and how to clear it (09 May 26):
  - Physical RAM held but unused:   5.27 GB RSS - 3.10 GB data = ~2.17 GB
  - Root cause:                     large DEL sweep freed arenas; pages not returned
  - Fix (no restart):               CONFIG SET activedefrag yes
  - Expected outcome:               ratio drifts toward ~1.25 over hours
  - Watch:                          ratio must NOT drop below 1.0 (= swap)

1. Read the direction, not just the magnitude. Above 1.5 is wasted RAM (an efficiency problem with a non-disruptive fix). Below 1.0 is swap (a latency emergency). The same card surfaces both, but they are opposite problems demanding opposite urgency.
2. Big deletes and TTL sweeps cause expected spikes. A high ratio right after a mass deletion or a wave of key expirations is normal allocator behaviour. Active defragmentation usually resolves it without a restart; a restart is the last resort, not the first.
3. Never let the ratio fall below 1.0. A sub-1.0 reading means Redis is swapping, the single worst thing for a latency-sensitive store. Treat it as an incident: confirm with vmstat / the OS, reduce dataset size or maxmemory, add RAM, or move data off the box. Pair with Command Latency p95 (ms), which will spike hard during swap.

​

Sibling cards DBAs should reference together

​

Reconciling against the source

INFO memory for mem_fragmentation_ratio, used_memory_rss, used_memory, used_memory_peak, allocator_frag_ratio, allocator_rss_ratio, and mem_allocator (confirm it is jemalloc). The allocator_* ratios in Redis 4+ isolate allocator-level fragmentation from process-level RSS. MEMORY DOCTOR for a plain-language diagnosis Redis itself generates about memory health, including fragmentation advice. MEMORY STATS for a detailed breakdown of where memory is going (dataset, overhead, replication buffers, etc.). The OS view: ps -o rss= -p <pid>, /proc/<pid>/status (VmRSS), vmstat, and free -m. If mem_fragmentation_ratio < 1.0, confirm swap usage with vmstat (the si/so columns) or free.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre