Skip to content 
Redis defragmentation reduces the actual RAM footprint by Memory Fragmentation reduce during normal operation, thereby preventing outliers in the RSS I avoid this. This allows me to keep latency consistent, reduce costs, and achieve reliable Redis memory optimization without requiring restarts.
Key points
- Active Defragmentation runs online and moves objects incrementally.
- INFO memory provides key metrics for trends and thresholds.
- Configuration Controls CPU budget, scan depth, and start thresholds.
- Data model and cache tuning help minimize fragmentation over the long term.
- Monitoring and alerts help prevent costly surprises.
Why Memory Fragmentation Occurs in Redis
I work with an in-memory database that contains objects more varied It constantly creates, modifies, and deletes memory; in the process, free RAM is gradually broken down into small blocks. These blocks add up to a significant total, but they are not contiguous, which causes the RSS to exceed the user data by a significant margin and thus Costs and drives up latency. By default, Redis uses jemalloc, which manages memory in classes, runs, and pages, which can result in partially filled pages. When many such partially filled pages exist, the gap between `used_memory` and RSS grows noticeably. This is precisely where the instance loses efficiency, even though I’m not holding any additional content. Active Defragmentation specifically addresses this pattern and gently cleans up the heap.
How Active Defragmentation Works Internally
Starting with Redis 4.0, online defragmentation moves candidates from thin moves occupied runs to more densely occupied areas and frees up old pages. I benefit from this because this work is performed in short cycles, thereby avoiding latency spikes. Before each step, Redis checks metrics such as mem_fragmentation_ratio and allocator_frag_ratio against configured thresholds. If there is sufficient fragmentation, the process scans the keyspace in chunks and migrates suitable objects while adhering to the specified CPU-Budget respected. This process repeats continuously until the RSS-to-heap ratio returns to normal. This reduces the footprint without requiring me to schedule a reboot.
INFO memory: How to Interpret Key Figures Correctly
Before I step in, I read the INFO I monitor memory metrics and focus on trends rather than individual readings. The `mem_fragmentation_ratio` shows me the ratio of RSS to used heap; values around 1.0–1.5 are often not a cause for concern, but persistent outliers above that range require attention. With `mem_fragmentation_bytes`, I can identify the absolute potential for savings, which is important for a realistic cost-benefit analysis. `allocator_frag_ratio` and `allocator_frag_bytes` provide additional context regarding the allocator’s behavior. If `active_defrag_running` is active, I can immediately see whether defragmentation is actually running and consuming CPU resources. Based on these facts, I make decisions rather than relying on gut feelings, and thus cache Targeted tuning.
| Metrics | Description | reference value | Action |
|---|---|---|---|
| mem_fragmentation_ratio | RSS Regarding Internal Heap Usage | ≈ 1.0–1.5 normal; > 1.5—check | Monitor the trend; if it exceeds 1.5, conduct a more in-depth analysis |
| mem_fragmentation_bytes | Absolute Fragmentation in Bytes | Relevant starting at ≈ 100 MB per instance | Assess potential, consider defragmenting |
| allocator_frag_ratio | Heap Fragmentation According to the Allocator | > 1.4 indicates a need for action | Enable defragmentation, fine-tune parameters |
| allocator_frag_bytes | Absolute overhead of the allocator | High double-digit to triple-digit MB | Adjust the CPU budget based on potential |
| active_defrag_running | Defragmentation Status and Activity | 0/1 depending on condition | Check for 1 latency and throughput |
Configuration: Recommended Default Settings and Effects
I switch activate defrag I configure it specifically and set conservative initial values so that the process starts up gently. With `active-defrag-ignore-bytes` (e.g., 100mb), I prevent unnecessary work on small heaps. The thresholds `active-defrag-threshold-lower` (e.g., 10) and `-upper` (e.g., 100) define when defragmentation starts and when it reaches its maximum speed. I control the CPU window using `active-defrag-cycle-min` (e.g., 1) and `-max` (e.g., 25), while `active-defrag-max-scan-fields` limits the scan depth in structured data types. For a quick overview of tuning relationships, I like to use concise background information such as Redis Memory Management. Based on initial measurements, I adjust the values incrementally until the latencies and performance gains are appropriately balanced; these Setting I then permanently save it in redis.conf.
Keep an Eye on CPU Budget and Latencies
I understand that defragmentation uses CPU resources, so I check Latency and throughput immediately after activation. If P99 values rise, I lower `active-defrag-cycle-max` or reschedule the task for less busy time slots. In addition, I offload the main workload by moving locks to an asynchronous process, thereby reducing the duration of individual operations. Helpful additions such as Redis Lazy Free I eliminate background storage, which noticeably reduces the load on the main thread. I also check whether long execution times are due to specific keys or structures, and optimize the affected data models first. This way, I maintain a balance between cost savings and Throughput.
Best Practices for Production Use
I assess fragmentation before I take action, and I take everyone into account Metrics from the same sample, so that the ratios are accurate. A `mem_fragmentation_ratio` below 1.0 indicates a risk of the kernel swapping; in that case, I check the RAM and swappiness settings instead of treating defragmentation as a cure-all. For actual fragmentation, I set realistic lower and upper limits and monitor `allocator_frag_bytes` as an indicator of whether defragmentation is worthwhile. In the first few minutes after activation, I closely monitor error counts, latencies, and timeouts. If side effects occur, I reduce the CPU budget or pause defragmentation until I’ve found the cause. Stable operation Values I document them and save them in redis.conf or in automation templates.
Structured Data Models to Combat Fragmentation
I'll start by reducing overhead in the Keys Personally: Shorter identifiers save bytes per entry and reduce variance. For object structures, I choose hashes over many individual keys because Redis packs small hash fields tightly. For serialized values, I use binary formats like MessagePack instead of bulky JSON strings. I minimize large, highly compressible content using lightweight methods like Snappy to reduce the frequency of reallocations. I also set TTLs wherever data becomes stale to prevent the keyspace from growing unchecked. This combination of decisions reduces the need for defragmentation later on and keeps the heap compact.
Set Up Monitoring and Alerts
I'm incorporating mem_fragmentation_ratio, allocator_frag_ratio, used_memory, and active_defrag_running into my Monitoring and plot trend curves. I don’t trigger thresholds rigidly; instead, I link them to trends over time windows so that short-term spikes don’t dictate the duty schedule. I give alerts unique names and add runbooks that outline possible responses. These responses include activating defragmentation, adjusting CPU windows, checking the data model, and performing system tuning to prevent swap effects. In addition, I separate metrics by instance so that individual outliers don’t get overlooked. With this discipline, I identify risks early and maintain the Performance plannable.
Specifically Account for Persistence and Copy-on-Write
I plan to defragment in the context of BGSAVE and AOF rewrite because fork operations trigger copy-on-write (CoW). Any page that changes after the fork is duplicated—the more fragmented and „dirty“ the heap, the greater the additional space required. That’s why I prefer to run defragmentation before planned persistence windows to create dense pages and reduce CoW amplification. In addition, I reserve operational headroom: Depending on the mutation rate, I allocate 20–50 % in addition to the used heap to ensure that RDB saves and AOF rewrites complete without an OOM. Replication buffers, client output buffers, and AOF rewrite buffers are included in this reserve. The result: shorter persistence windows, fewer RSS spikes, and more stable latencies during backups.
Jemalloc Fine-Tuning and Operating System Influence
I check whether jemalloc is running with a background thread enabled that returns free pages. Background purge and sensible decay settings ensure that freed memory actually reaches the kernel and doesn’t remain „muzzy“ or „dirty“ indefinitely. I disable Transparent Huge Pages because they typically harm Redis workloads and make CoW more expensive. I consistently avoid swapping; I consider a `mem_fragmentation_ratio` < 1.0 a warning sign and check system parameters before making any changes to Redis. My goal is a tight coupling between the heap and RSS: Defrag cleans up, jemalloc frees memory, and the OS quickly reclaims the pages—without any unexpected setbacks when accessing them again.
Data Type-Specific Tuning in Practice
I consistently use compact representations: Hashes and sorted sets remain compact for a long time thanks to listpack formats, as long as I set the limits appropriately. Lists benefit from Quicklist packing, and sets from intset, as long as they contain only integers. I regularly trim streams (e.g., using XTRIM) to prevent infinite growth and reallocations. For ZSETs with few entries, I set higher packing limits; for very large ZSETs, I reduce them again to limit costly repackaging. This fine-tuning reduces the number and variance of small allocations—which is precisely where fragmentation often occurs. The key point remains: I first measure actual object sizes and growth rates, then adjust thresholds, rather than simply optimizing based on intuition.
Maxmemory, Eviction, and Operational Headroom
I set `maxmemory` so that there is enough space not only for user data but also for overhead, replication, CoW spikes, and fragmentation. Eviction policies influence allocation dynamics: LRU/LFU evict more frequently, creating smaller gaps, while „noeviction“ increases the risk of critical errors when headroom is lacking. My approach: realistic watermarks and a policy that matches the access pattern. I also monitor client-related buffers, Pub/Sub spikes, and SCRIPT/pipeline spikes—all three of which can cause short-term memory spikes. Defrag itself runs most efficiently when evictions aren’t occurring simultaneously; that’s why I choose windows with stable load or throttle the defrag budget during periods of recognizable peak demand.
Sharding, Replication, and Rolling Defrag
I prefer to scale horizontally before a single instance bursts at the seams. Multiple medium-sized shards typically fragment less than a single massive process containing highly heterogeneous objects. In replicated setups, I perform defragmentation incrementally as a rolling process: first offload the replica and check it, then perform a failover and clean up the previous master. This way, I keep user paths stable and reduce risk. For clusters, I also pay attention to slot distribution: Heterogeneous hot keys concentrated on a few shards result in uneven allocation behavior and thus different fragmentation profiles. A balanced slot distribution visibly smooths out these effects.
Test Strategy, Load Profiles, and Safe Activation
I simulate realistic load patterns: write-dominant, read-heavy, burst insertions, TTL operations—everything that happens in everyday use. In staging, I first enable Defrag conservatively and measure P50/P95/P99 latencies, throughput, fork duration, and the evolution of mem_fragmentation_bytes. Afterward, I increase the CPU budget in small increments. I change configurations live using CONFIG SET, but always keep fallback levels ready. I log when and with which parameters Defrag ran so that correlations with metrics are reliable. Important: I also test what happens when Defrag is paused. When Defrag pauses, latencies must not „lock in“ permanently. This is the only way I can prove that the optimization is actually working and not just shifting symptoms.
Borderline Cases and Common Pitfalls
I anticipate situations where defragmentation has little effect: very uniform object sizes, huge individual objects, or workloads that immediately undo any consolidation due to a constant high rate of change. Modules that manage their own memory outside of jemalloc are beyond the scope of this mechanism—my tuning only affects them indirectly. Another classic issue is „empty“ but massive structures that maintain administrative overhead (e.g., large sets after extensive deletion). In such cases, refactoring the data model works better than any defrag budget. Finally, I check whether I’m inadvertently slowing down defragmentation: scan depth set too low, cycle-max values set too low, or thresholds that are never reached. Only once these hurdles have been cleared do I expect to see real savings.
Troubleshooting: When a Restart Makes Sense
If defragmentation stalls even though the `allocator_frag_ratio` remains high, I plan to perform a controlled Switches or a quick restart. In high-availability setups, a scheduled failover replaces the active instance, and the newly loaded process starts with a compact heap. I also check whether the server is actually running with jemalloc, because Active Defragmentation doesn't work without this allocator. For a deeper understanding of memory fragmentation, I find it helpful to consult clear, concise articles on Memory fragmentation. Before each restart, I record the latest measurement values to objectively assess effectiveness. Only when the measurement and the effect match do I mark the incident as resolved and make a note of it Learning Outcomes for the future.
Summary in brief
I use Active Defragmentation, ...to keep RSS at a reasonable level without risking service interruptions. Clear thresholds, conservative initial values, and a transparent CPU budget keep the service responsive. A suitable data model with compact keys, hashes, binary serialization, and consistent TTLs reduces the need for cleanup later on. Effective monitoring with meaningful alerts guides my interventions and prevents surprises. If defragmentation doesn’t resolve the issue, I plan failover and restarts deliberately rather than hoping for the best. This way, I save RAM and keep latencies constant and run Redis reliably—with measurable benefits in terms of cost and user experience.
