Redis mem_fragmentation_ratio high: jemalloc fragmentation and active defrag

A mem_fragmentation_ratio sustained above 1.5 on a production instance means Redis holds significantly more physical memory (RSS) than its logical dataset size (used_memory), wasting RAM that could hold data or absorb spikes. This is not a memory leak. Redis uses jemalloc by default, which does not return freed pages to the OS eagerly. Deleted or resized keys leave holes in allocator arenas, inflating RSS while used_memory stays flat or drops.

The immediate risk is OOM kill. The Linux OOM killer targets RSS. An instance with 20 GB of logical data and a fragmentation ratio of 2.0 occupies 40 GB RAM. A background fork for RDB or AOF copy-on-write can push RSS over a 48 GB host or cgroup limit and kill the process, even though the dataset appears to fit.

Ignore the ratio on instances with less than 50 MB of used_memory. jemalloc’s minimum allocation granularity dominates at small scale. On larger instances, sustained elevation above 1.5 is a capacity incident.

What this means

mem_fragmentation_ratio is used_memory_rss divided by used_memory. A value of 1.0 to 1.1 is optimal; 1.1 to 1.5 is common for active workloads. Sustained values above 1.5 indicate significant waste. Values below 1.0 on instances larger than 100 MB suggest swap, which is catastrophic for latency.

This ratio is coarse. It includes process overhead such as code segments, shared libraries, and stack space, not just allocator fragmentation. For precision, Redis 5.0 and later expose allocator_frag_ratio (allocator_active / allocator_allocated), which isolates true jemalloc external fragmentation. Redis does not document a threshold ratio: an elevated allocator_frag_ratio with substantial allocator_frag_bytes indicates real external fragmentation, while a high ratio with only a few megabytes of fragmentation is not an issue.

The ratio is also unreliable after peak memory events. The allocator holds freed pages for reuse rather than releasing them to the OS. If Redis briefly filled memory with a bulk import and then deleted the keys, used_memory drops but RSS remains at the peak. This produces an artificially high ratio that may not reflect active fragmentation. In this scenario, mem_fragmentation_bytes (the absolute difference between RSS and used_memory) is often more actionable than the ratio itself.

flowchart TD
    A[mem_fragmentation_ratio above 1.5] --> B{used_memory below 50MB?}
    B -->|Yes| C[Noise: ignore]
    B -->|No| D{allocator_frag_ratio elevated with substantial allocator_frag_bytes?}
    D -->|Yes| E[True jemalloc fragmentation]
    D -->|No| F[RSS padding or process overhead]
    E --> G{active_defrag_running?}
    G -->|Yes| H[Check hits and misses ratio]
    G -->|No| I[Enable activedefrag or run MEMORY PURGE]
    F --> J[Check used_memory_peak vs used_memory]
    H --> K{Hits high?}
    K -->|Yes| L[Defrag working: wait or tune CPU]
    K -->|No| M[Workload skips large fields or defrag ineffective]

Common causes

Quick checks

Run these read-only commands to characterize the situation before making changes.

# Check top-level fragmentation and memory totals
redis-cli INFO memory | grep -E "used_memory:|used_memory_rss:|mem_fragmentation_ratio:|used_memory_peak:"

# Check allocator-level fragmentation for precision (Redis 5.0+)
redis-cli INFO memory | grep -E "allocator_frag_ratio:|allocator_rss_ratio:"

# Check active defrag status and effectiveness
redis-cli INFO memory | grep active_defrag_running
redis-cli INFO stats | grep -E "active_defrag_hits|active_defrag_misses"
redis-cli CONFIG GET activedefrag

# Run built-in diagnostics (Redis 4.0+)
redis-cli MEMORY DOCTOR

# Check for THP interference
cat /sys/kernel/mm/transparent_hugepage/enabled

How to diagnose it

1. Filter out noise. If used_memory is below 50 MB, ignore the ratio.
2. Check for post-peak artifact. Compare used_memory_peak to current used_memory. If the peak is many times larger than the current value, the high ratio is likely residual RSS from prior bulk allocations.
3. Isolate true allocator fragmentation. On Redis 5.0+, inspect allocator_frag_ratio and allocator_frag_bytes. If the ratio is elevated and the absolute fragmentation is substantial, you have genuine jemalloc external fragmentation. If the ratio is low but mem_fragmentation_ratio is high, the gap is process overhead or RSS padding.
4. Assess active defrag state. If activedefrag is disabled and you are on Redis 4.0 or later, the instance is not attempting to compact live objects. If it is enabled but active_defrag_misses is high relative to active_defrag_hits, defrag is working hard without reducing fragmentation. This can happen when large hash or sorted set fields exceed active-defrag-max-scan-fields (default 1000) and are skipped per scan cycle.
5. Check for THP interference. If Transparent Huge Pages are not set to never, jemalloc’s page management is impaired, which can amplify fragmentation and worsen fork latency. The enabled file should read [never].
6. Correlate with persistence events. used_memory_rss spikes temporarily during RDB or AOF rewrite because of copy-on-write. If the ratio is elevated only during rdb_bgsave_in_progress or aof_rewrite_in_progress, the condition is transient.

Metrics and signals to monitor

Fixes

Post-peak RSS retention: run MEMORY PURGE

If the fragmentation is residual from a prior peak, MEMORY PURGE asks jemalloc to purge dirty pages so they can be reclaimed. This is a jemalloc-specific operation; it is a NOOP when using libc or tcmalloc. It reduces used_memory_rss without changing used_memory. On large heaps this command can be slow. Run it during a low-traffic window.

# Ask jemalloc to release dirty pages to the OS
redis-cli MEMORY PURGE

Sustained fragmentation: enable active defrag

For Redis 4.0 and later, enabling active defragmentation moves live objects to fresh memory and releases fragmented pages. This consumes CPU and can add latency if misconfigured. Enable it live to test:

redis-cli CONFIG SET activedefrag yes

The default thresholds are:

• active-defrag-ignore-bytes 100mb
• active-defrag-threshold-lower 10
• active-defrag-threshold-upper 100
• active-defrag-cycle-min 1
• active-defrag-cycle-max 25
• active-defrag-max-scan-fields 1000

Do not lower active-defrag-ignore-bytes without reason. The threshold exists to prevent the CPU cost of defrag on small absolute fragmentation. If mem_fragmentation_bytes is below 100 MB, defrag will not trigger even if the percentage threshold is met.

If defrag is enabled but the ratio does not drop, check whether your workload uses large hash or sorted set fields. Objects with fields above the active-defrag-max-scan-fields threshold are skipped during each cycle, which limits effectiveness on those key types. You can raise the scan limit, but doing so increases the CPU cost per cycle.

Version-specific active defrag bugs

Before applying active defrag as a long-term fix, check your Redis version. On Redis 7.2, a known bug can cause RSS to grow until the host runs out of memory even when active defrag is enabled (redis/redis issue #13612, reported on 7.2.5). It is fixed in Redis 7.4 (PR #13058). If you observe this behavior, upgrade to Redis 7.4 or later; a restart is only a temporary mitigation. On Redis 8.0, enabling active defrag can make cron-based timers run twice as fast (redis/redis PR #14081). The fix shipped in Redis 8.2.2. Upgrade to 8.2.2 or later if you use active defrag.

Disruptive fallback: restart

Restarting Redis resets RSS and eliminates fragmentation immediately. This is effective but causes downtime, cache warmup, and replication delay if the instance is a primary. Use it only when MEMORY PURGE and active defrag have failed, or when you hit version-specific bugs such as unbounded RSS growth despite active defrag. Plan the restart during a maintenance window.

System-level: disable Transparent Huge Pages

If THP is enabled, disable it. The following commands take effect immediately but do not survive reboot:

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

Persist the change in your system configuration (for example, sysctl or grub) if required.

Prevention

• Monitor allocator_frag_ratio on Redis 4.0+ alongside mem_fragmentation_ratio to catch true fragmentation early. On large instances, track mem_fragmentation_bytes for an absolute view of wasted memory.
• Review MEMORY MALLOC-STATS periodically to understand arena-level fragmentation. Sustained growth in dirty or muzzy pages indicates the allocator is struggling to reuse memory efficiently.
• Size memory limits with fragmentation headroom. Persistent instances should keep used_memory below roughly 50% of physical RAM or maxmemory, whichever is tighter, to leave space for RSS overhead and COW during fork.
• Avoid mass deletion patterns that leave jemalloc arenas sparse. When possible, use expiration with jitter rather than bulk deletes.
• Evaluate active defrag effectiveness through active_defrag_hits and active_defrag_misses rather than enabling it and forgetting it.

How Netdata helps

• Netdata collects mem_fragmentation_ratio, used_memory, and used_memory_rss natively, so you can correlate RSS growth with logical memory changes.
• On Redis 4.0+, Netdata also surfaces allocator_frag_ratio, helping you distinguish allocator waste from process overhead.
• Netdata’s alert templates filter out tiny instances, suppressing noise on instances below 50 MB.
• You can correlate active_defrag_running with CPU utilization and command latency to spot when defrag itself is becoming a performance cost.
• RSS and used_memory are plotted on the same charts, exposing post-peak deallocation patterns.

Related guides

• How Redis actually works in production: a mental model for operators
• Redis aof_last_write_status:err: AOF write failures and recovery
• Redis appendfsync always latency: durability vs throughput trade-offs
• Redis big keys: finding the giant key that blocks the event loop
• Redis blocked_clients growing: dead consumers vs healthy queues
• Redis BUSY Redis is busy running a script: blocking Lua and how to recover
• Redis Can’t save in background: fork: Cannot allocate memory - diagnosis and fix
• Redis client output buffer overflow: slow consumers and client-output-buffer-limit
• Redis cluster_slots_pfail > 0: impending node failure in a cluster
• Redis CLUSTERDOWN / cluster_state:fail: slot coverage and recovery
• Redis connected_clients climbing: connection leak detection
• Redis connected_slaves dropped: detecting replica disconnects on the primary