Redis Memory Fragmentation Degrading Performance
warningProactive Health
Memory fragmentation ratio exceeding 1.5, causing Redis to consume significantly more RAM than allocated data, risking OOM and swap usage.
Prompt: “My Redis instance shows mem_fragmentation_ratio at 1.8 even though we're only using 60% of allocated memory - is this fragmentation normal or do I need to enable active defragmentation, and will it impact production performance?”
Agent Playbook
When an agent encounters this scenario, Schema provides these diagnostic steps automatically.
When investigating Redis memory fragmentation, start by confirming the fragmentation ratio is genuinely problematic, then quantify the gap between logical and physical memory usage to understand the impact. Next, check if fragmentation is triggering cache evictions or approaching memory limits, and finally evaluate whether active defragmentation is safe to enable given your workload characteristics.
1Confirm fragmentation severity and trend
Check `redis-memory-fragmentation-ratio` over time, not just a single reading. A ratio of 1.8 is concerning (healthy is 1.0-1.5), but you need to know if it's stable, climbing, or temporary. If it's been steady at 1.5-2.0 for hours and your workload hasn't changed dramatically, you have chronic fragmentation. A spike after a bulk delete or TTL expiry wave might self-correct. Plot this metric over the last 24-48 hours to distinguish between chronic fragmentation and transient spikes.
2Quantify the memory waste
Compare `redis-mem-rss` (physical memory the OS sees) to `redis-memory-used` (logical memory Redis thinks it's using). With a 1.8 fragmentation ratio, if `redis-memory-used` shows 6GB, `redis-mem-rss` should be around 10.8GB — that's 4.8GB of wasted memory. Now check `redis-memory-maxmemory`: if your RSS is approaching maxmemory even though logical usage is only 60%, you'll hit OOM before you expect. This tells you how urgent the problem is.
3Check for eviction pressure and cache performance degradation
The real test is whether fragmentation is causing operational problems. Look for the pattern described in the `memory-fragmentation-amplifies-cache-eviction-pressure` insight: are keys being evicted even though `redis-memory-used` is well below `redis-memory-maxmemory`? This happens because the OS sees RSS, not logical memory, and Linux OOM killer or Redis's own maxmemory enforcement uses physical memory. If you're seeing unexpected evictions or declining cache hit rates while logical memory looks healthy, fragmentation is actively harming you.
4Identify workload patterns causing fragmentation
Fragmentation typically comes from frequent key deletions, expired keys with TTLs, or heavy use of data types that resize (lists, sets, sorted sets with many adds/removes). If you recently did a bulk delete, large TTL expiry wave, or changed your key patterns (e.g., switched from a few large keys to many small keys), that's your culprit. Understanding the cause helps you decide between active defragmentation (treats the symptom) versus workload changes (addresses the root cause).
5Evaluate active defragmentation safety and impact
If you're on Redis 4.0+, active defragmentation is available but comes with CPU cost. Start conservatively: enable it with low thresholds (activedefrag yes, active-defrag-threshold-lower 10, active-defrag-cycle-min 1, active-defrag-cycle-max 25). Monitor CPU usage closely — defragmentation runs in the main thread and will add latency. For production, it's safer than a restart if you can tolerate 5-15% CPU overhead during defrag cycles. If you're on an older Redis version or can't afford the CPU cost, plan a controlled restart during a maintenance window instead.
6Review historical peak memory usage
Check `redis-memory-peak` to see if you've historically consumed more memory than you currently are. If peak is much higher than current usage, it suggests you had a past spike that created fragmentation holes that never got filled. This reinforces that fragmentation is from previous workload patterns, not current ones, making active defragmentation or a restart your best options rather than workload tuning.
Technologies
RedisRelevant Metrics
Monitoring Interfaces
Redis Datadog
Redis PrometheusRedis Native Metrics