Your Redis instance looks healthy — low CPU, plenty of free memory, stable connection count. Then latency spikes out of nowhere, and you spend an hour debugging before realizing the culprit was memory fragmentation. It's one of the most common Redis performance issues that teams miss because it doesn't show up in the obvious metrics. Here's how to catch it before it bites you.
What Redis Memory Fragmentation Actually Is
Redis allocates memory in chunks through its memory allocator (jemalloc by default). Over time, as keys are created, updated, and deleted at varying sizes, gaps form between those chunks — memory the OS has handed to Redis but Redis isn't actively using for data. The ratio between the memory Redis holds from the OS versus the memory Redis actually uses for data is your fragmentation ratio. A ratio of 1.0 means perfect efficiency. Anything significantly above 1.5 is where problems start, and above 2.0 you'll almost certainly see latency impact.
Fragmentation hurts performance because the allocator has to work harder to find contiguous memory regions, and in extreme cases Redis will trigger active defragmentation, which competes with your normal workload. The insidious part: your application sees slow responses but your system-level memory graphs look fine.
The Metrics You Need to Watch
Everything you need lives inside Redis INFO output. Run this against your instance:
redis-cli -h 127.0.0.1 -p 6379 INFO memory
The key fields to extract:
- used_memory — bytes Redis allocated for data
- used_memory_rss — bytes the OS reports Redis is using (resident set size)
- mem_fragmentation_ratio — the ratio of rss to used_memory; this is your primary signal
- mem_fragmentation_bytes — absolute bytes wasted, useful for context
- active_defrag_running — 1 means Redis is actively defragmenting right now
- allocator_frag_ratio — fragmentation inside the allocator itself, separate from OS-level fragmentation
Don't rely on mem_fragmentation_ratio alone. A ratio of 1.8 on an instance using 500 MB of data is very different from 1.8 on an instance using 50 GB. Always look at mem_fragmentation_bytes alongside it — if you're wasting 200 MB, that's a real problem; if you're wasting 4 MB, it's noise.
Setting Meaningful Alert Thresholds
Generic thresholds don't work well here because workloads differ. That said, sensible starting points are:
- mem_fragmentation_ratio > 1.5 — warning; begin watching closely
- mem_fragmentation_ratio > 2.0 — critical; investigate immediately
- mem_fragmentation_bytes > 500 MB — critical regardless of ratio
- active_defrag_running = 1 for more than a few minutes — worth noting; it means Redis already decided things were bad enough to act
If you're using Prometheus with the redis_exporter, you can alert on these directly. A Prometheus alerting rule for the critical case looks like this:
- alert: RedisHighFragmentation expr: redis_memory_used_rss_bytes / redis_memory_used_bytes > 2.0 for: 5m labels: severity: critical annotations: summary: "Redis memory fragmentation ratio above 2.0 for 5 minutes"
The for: 5m clause matters. Fragmentation naturally spikes briefly during bulk deletes or expiry storms, so you want to alert on sustained high fragmentation, not momentary blips.
How to Reduce Fragmentation When It Gets Bad
Once you've caught fragmentation early, you have a few options depending on severity:
- Enable active defragmentation — if you're on Redis 4.0+, you can turn this on at runtime: redis-cli CONFIG SET activedefrag yes. Redis will gradually repack memory in the background. Set active-defrag-ignore-bytes 100mb and active-defrag-enabled yes in your config to make it permanent.
- Restart Redis — the nuclear option, but sometimes the fastest path. Redis will reload from an RDB or AOF snapshot and start with a clean memory layout. Only practical if you have replication set up and can failover cleanly.
- Tune your key expiry and eviction policy — fragmentation often worsens with volatile-lru or allkeys-lru eviction under memory pressure. If you're evicting constantly, reconsider your maxmemory setting or data model.
- Reduce key churn for large values — frequent updates to large string or hash values are a primary driver. Where possible, batch updates or restructure data to avoid constantly reallocating big chunks.
Check whether active defrag is already enabled before you turn it on: redis-cli CONFIG GET activedefrag. If it's already yes and fragmentation is still climbing, you likely have a structural data problem rather than a tuning one.
Making This Easier to Catch Automatically
The manual approach — periodically running INFO memory and checking the numbers — works fine until you have more than one Redis instance or a team that doesn't watch dashboards closely. Most latency incidents caused by fragmentation are preventable, but only if someone notices the ratio creeping up over hours or days before it becomes critical.
This is exactly where a tool like Opservo helps — it continuously monitors Redis memory metrics, surfaces fragmentation trends in plain English, and can alert your team before the ratio crosses critical thresholds rather than after latency has already degraded. Instead of digging through INFO output during an incident, you get an early warning with context.
Whether you go the manual route or automate it, the core habit is the same: treat mem_fragmentation_ratio as a first-class metric alongside hit rate and latency. It's not exotic telemetry — it's one of the most reliable early warning signals Redis gives you, and it's sitting there in INFO memory waiting to be used.
Point readers to Opservo's free 2-server plan as the easiest way to get continuous fragmentation alerting without building a Prometheus stack. — one command installs a read-only agent and your first findings arrive in five minutes: start free. Related: blog how to monitor redis memory and eviction.
Originally published on the Opservo blog.
Top comments (0)