Reclaiming Storage Space in Redis: Strategies and Limitations

Redis, a powerful in-memory data structure store, serves as a database, cache, and message broker. While its in-memory architecture delivers exceptional performance, it also presents unique memory management challenges. This report examines strategies for reclaiming storage space in Redis—covering memory allocation mechanisms, practical reclamation techniques, and optimization best practices. Understanding these concepts is essential for maintaining optimal Redis performance while managing system resources efficiently.

Redis Memory Management Fundamentals

Redis handles memory differently from traditional databases. When data is deleted, the memory isn’t automatically returned to the operating system—a behavior common to most memory allocators. Redis retains this freed memory for future operations[2][13], optimizing performance by reducing allocation overhead but potentially causing confusion during system monitoring.

Redis follows a “high-water mark” principle for memory allocation. After reaching peak memory usage, it maintains that footprint even after data deletion. As Redis creator Salvatore Sanfilippo explains: “Redis always uses the peak memory usage during its life, unless you restart it from scratch. So basically if you want to use 5 GB for 10 seconds, and all the other day you use 100 MB, you need 5 GB of memory free always as after the peak memory usage it will never release the memory again.”[10] This design choice stems from technical considerations around memory fragmentation and allocation efficiency.

Memory allocation in Redis relies on allocators like jemalloc, which manages memory blocks internally. Upon deletion, jemalloc retains memory within the Redis process rather than returning it to the operating system. While this approach reduces fragmentation and enhances performance, it makes reducing Redis’s memory footprint challenging without more dramatic measures[13]. Effective Redis memory management requires understanding not just key-value storage, but also memory overhead for data structures, replication buffers, and internal components.

Methods for Reclaiming Memory in Redis

Despite Redis’s tendency to retain allocated memory, several methods exist for reclaiming storage space. The most straightforward approach is restarting the Redis server, which releases all memory to the operating system and resets the memory footprint[10]. While effective, this method requires downtime and should be used carefully in production.

Redis 4.0.0 introduced the MEMORY PURGE command for targeted memory reclamation without restarts. This command attempts to reclaim memory by purging dirty pages[12]. However, MEMORY PURGE only works with the jemalloc allocator and acts as a no-op for others[12]. Its effectiveness varies based on fragmentation patterns and allocation history, but it offers a way to reclaim memory without service interruption.

Another option involves clearing the Redis cache entirely. The redis-cli command provides several methods: redis-cli flushall deletes all keys from all databases, while redis-cli flushdb removes keys from only the selected database[7]. Since Redis 4.0.0, these commands can run asynchronously using the async parameter (e.g., redis-cli flushall async), preventing server blocks during operation[7]. While these commands remove data effectively, they don’t guarantee immediate memory return to the operating system.

For multi-server environments, automation tools like Ansible can clear caches across all instances simultaneously. The command ansible all -m command -a ‘/usr/bin/redis-cli flushall’ executes the flushall operation across every server in an Ansible inventory[7]—particularly valuable for large-scale deployments where manual intervention would be impractical.

Memory Optimization Strategies

Beyond direct memory reclamation, Redis offers several optimization strategies to reduce memory usage and improve efficiency. A key approach involves configuring maxmemory settings and eviction policies. The maxmemory configuration limits Redis memory usage, triggering the configured eviction policy when reached[6][11]. Google Cloud’s Memorystore for Redis uses maxmemory-gb for this setting, which defaults to instance capacity but may need adjustment based on usage patterns[6].

Redis supports these eviction policies when maxmemory is reached:

• volatile-lru: removes keys with expiry settings based on least recently used algorithm
• volatile-ttl: removes keys with expiry settings based on shortest remaining time to live
• volatile-random: removes random keys with expiry settings
• allkeys-lru: removes any keys based on least recently used algorithm
• allkeys-random: removes random keys regardless of expiry settings
• noeviction: prevents key eviction, causing write operations to fail when memory limit is reached[11]

These policies let administrators tailor Redis behavior to specific application needs, balancing data retention with memory constraints.

Redis also employs special encoding for small aggregate data types. Since Redis 2.2, data types like Hashes, Lists, Sets of integers, and Sorted Sets use more efficient memory encodings below certain thresholds[13]. These optimizations can reduce memory usage up to 10 times (averaging 5 times savings)[13]. Administrators can configure these encoding thresholds through directives like hash-max-listpack-entries and zset-max-listpack-value.

For extreme memory constraints, compiling Redis as a 32-bit binary significantly reduces per-key memory usage through smaller pointers[13]. While this limits maximum memory to 4GB, it serves applications with moderate data volumes and strict memory constraints effectively. The make 32bit compilation command enables this option, and RDB/AOF files remain compatible between 32-bit and 64-bit instances[13].

Monitoring and Diagnosing Memory Issues

Effective memory reclamation starts with proper monitoring. Redis provides several analysis commands: MEMORY USAGE reports bytes required for key-value storage, including administrative overhead[14]. For instance, Redis v7.2.0 64-bit with jemalloc requires 56 bytes even for an empty string, due to internal structure overhead[14].

The MEMORY STATS command offers comprehensive memory analysis, breaking down server memory usage by component[15]. This output shows total allocated memory, peak usage, replication backlog, client connections, and database overhead[15]—helping identify major memory consumers.

System monitoring should track the memory usage ratio between Redis and total system memory[6]. This metric helps detect memory pressure that could impact performance. When this ratio approaches concerning levels, administrators should adjust the maxmemory-gb limit to ensure sufficient overhead for workload spikes[6].

Memory fragmentation significantly affects Redis efficiency. The mem_fragmentation_ratio (visible in Redis INFO output) shows the ratio between RSS and used memory[2]. A ratio well above 1.0 indicates fragmentation, where the allocator holds excess memory. Severe cases may require MEMORY PURGE or server restart.

Case Studies and Practical Applications

Real-world Redis memory reclamation reveals both capabilities and limitations. In one case, a Redis instance with 31.68G peak memory continued using 29.71G after deleting half its keys[2]—demonstrating the high-water mark principle where deletion doesn’t automatically reduce memory footprint.

Another study showed MEMORY PURGE releasing only 0.16 megabytes from a 75.61-megabyte Redis process[16]. This modest result illustrates how MEMORY PURGE effectiveness depends heavily on allocation patterns and fragmentation.

In web hosting, clearing Redis cache can improve performance when excessive caching creates memory pressure. However, SmartHost notes that “too frequent clearing of redis memory may result in slower performance of the site because the cache will have to be built from scratch each time.”[3] This highlights the balance between memory reclamation and caching benefits.

For database applications, configuring appropriate eviction policies often works better than manual cache clearing. One Redis administrator observed: “Losing the Redis DB (equivalent of redis-cli flushall) is something the Discourse app will recover from without major problems, but you will lose all sessions (forcing users to log in again) and some background state.”[8] This shows how memory reclamation carries functional implications.

Conclusion

Redis’s memory management architecture presents unique challenges for reclaiming storage space. While Redis doesn’t automatically return freed memory to the operating system after deletion, several effective management strategies exist—from configuration optimizations to direct interventions like MEMORY PURGE or server restarts.

Server restart remains the most definitive approach, completely resetting the memory footprint. For production systems where restarts aren’t practical, MEMORY PURGE offers a less disruptive option, though results vary. Cache-clearing commands remove data but don’t guarantee immediate memory return.

Successful memory management requires proactive optimization—proper eviction policies, efficient data type encoding, and vigilant monitoring. By understanding Redis’s memory principles, administrators can maintain optimal performance within its constraints while leveraging built-in capabilities. The key lies not in fighting Redis’s design but in working within its framework while maximizing its optimization features.

Sources

1. Redis Memory & Performance Optimization – Everything You Need … https://www.dragonflydb.io/guides/redis-memory-and-performance-optimization
2. why does the redis memory usage not reduce when del half of keys https://stackoverflow.com/questions/11698911/why-does-the-redis-memory-usage-not-reduce-when-del-half-of-keys
3. Clearing redis cache memory – we talk about hosting unofficial https://www.smarthost.eu/blog/clearing-redis-cache-memory
4. After lowering maxmemory, redis still has high RSS memory https://dba.stackexchange.com/questions/149866/after-lowering-maxmemory-redis-still-has-high-rss-memory
5. Redis persistence | Docs https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/
6. Memory management best practices | Memorystore for Redis https://cloud.google.com/memorystore/docs/redis/memory-management-best-practices
7. How to Clear Redis Cache {Deleting All Keys or from … – phoenixNAP https://phoenixnap.com/kb/clear-redis-cache
8. Discouse takes up a lot of disk space, mainly the redis_data folder https://meta.discourse.org/t/discouse-takes-up-a-lot-of-disk-space-mainly-the-redis-data-folder/255331
9. Redis Memory Test – eG Innovations https://www.eginnovations.com/documentation/Redis/Redis-Memory-Test.htm
10. Re: How does Redis release memory? – Google Groups https://groups.google.com/g/redis-db/c/ibhYDLT_n68
11. What does Redis do when it runs out of memory? – Stack Overflow https://stackoverflow.com/questions/5068518/what-does-redis-do-when-it-runs-out-of-memory
12. MEMORY PURGE | Docs – Redis https://redis.io/docs/latest/commands/memory-purge/
13. Memory optimization | Docs – Redis https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/memory-optimization/
14. MEMORY USAGE | Docs – Redis https://redis.io/docs/latest/commands/memory-usage/
15. MEMORY STATS | Docs – Redis https://redis.io/docs/latest/commands/memory-stats/
16. Memory Purge – Google Groups https://groups.google.com/g/redis-db/c/Xla2OQ0DxyI
17. How to Tune Redis to Handle Big Spikes in Traffic – Equinix Metal https://deploy.equinix.com/blog/distributed-caching-how-to-tune-redis-for-traffic-spikes/
18. Memory not becoming free after eviction of keys. #6290 – GitHub https://github.com/antirez/redis/issues/6290
19. Persistence options in Redis https://redis.io/learn/operate/redis-at-scale/persistence-and-durability/persistence-options-in-redis
20. Database memory limits | Docs – Redis https://redis.io/docs/latest/operate/rs/databases/memory-performance/memory-limit/
21. Redis FAQ | Docs https://redis.io/docs/latest/develop/get-started/faq/
22. Notes on Redis Memory Usage | Irrational Exuberance – Will Larson https://lethain.com/notes-on-redis-memory-usage/
23. Memory used only grows despite unlink/delete of keys. #7482 – GitHub https://github.com/redis/redis/issues/7482
24. Redis kill by os becuase of out of memory – Reddit https://www.reddit.com/r/redis/comments/1idryjl/redis_kill_by_os_becuase_of_out_of_memory/