Memory Fragmentation Remediation
warningProactive Health
Redis memory fragmentation ratio is high, indicating wasted memory that could lead to OOM even when logical used memory is below limits.
Prompt: “My Redis instance shows 6GB used memory but the actual RSS is 9GB, giving a fragmentation ratio of 1.5. We're getting closer to our memory limit but a lot of it seems to be wasted. Should I enable active defragmentation or restart the instance? What's causing this and how do I prevent it from happening again?”
Agent Playbook
When an agent encounters this scenario, Schema provides these diagnostic steps automatically.
When diagnosing Redis memory fragmentation, start by confirming the fragmentation ratio and gap between logical and physical memory, then assess whether it's causing operational issues like premature evictions. Only after understanding the impact should you choose between active defragmentation or a controlled restart, and finally investigate workload patterns to prevent recurrence.
1Confirm the fragmentation baseline and memory gap
Check `redis-memory-fragmentation-ratio` alongside `redis-memory-used` and `redis-mem-rss` to verify the actual waste. In your case, a ratio of 1.5 means 3GB of the 9GB RSS is fragmentation overhead. Ratios above 1.5 are concerning, and above 2.0 typically require immediate action. This gives you the baseline to measure any remediation efforts against.
2Assess how close you are to OOM conditions
Compare `redis-mem-rss` (your actual 9GB) against `redis-memory-maxmemory` to see your headroom. If RSS is within 10-15% of maxmemory, you're in the danger zone and need immediate action. If you have more headroom, you can afford to take a more measured approach with active defragmentation rather than an emergency restart.
3Check if fragmentation is causing cache evictions
Look for the pattern described in `memory-fragmentation-amplifies-cache-eviction-pressure`: when `redis-memory-fragmentation-ratio` is high, Redis may hit maxmemory limits on physical RSS even though `redis-memory-used` looks healthy. This causes premature key evictions and degraded cache hit rates. If you're seeing evictions while logical memory appears to have headroom, fragmentation is actively hurting performance.
4Determine if active defragmentation is available
Check your Redis version (4.0+ required) and whether activedefrag is enabled. Run `CONFIG GET activedefrag` and check the allocator with `MEMORY MALLOC-STATS`. Active defrag works best with jemalloc allocator and can reclaim fragmented memory without downtime, but it does consume CPU. If you're on an older version, your only option is a restart.
5Choose your remediation strategy based on urgency
If you have headroom and activedefrag is available, enable it with conservative settings (`activedefrag yes`, `active-defrag-cycle-min 5`, `active-defrag-cycle-max 25`) and monitor `redis-memory-fragmentation-ratio` over hours. If you're near OOM or activedefrag isn't available, schedule a controlled restart during a low-traffic window—restarts immediately reset fragmentation to near 1.0 but cause a temporary cache miss storm.
6Investigate workload patterns causing fragmentation
Fragmentation typically comes from mixing large and small keys, frequent key expirations, or heavy updates to variable-sized values. Look at your key size distribution (`DEBUG OBJECT` sampling) and operation patterns. If you're frequently updating strings that grow/shrink or running lots of APPEND operations, consider restructuring to use more consistent-sized values or separate large keys into their own keyspace to reduce fragmentation over time.
Technologies
RedisRelevant Metrics
Monitoring Interfaces
Redis Datadog
Redis PrometheusRedis Native Metrics