Introduction
Redis efficiently handles real-time data, but inefficient key expiry policies, suboptimal eviction strategies, and excessive memory fragmentation can degrade performance. Common pitfalls include using `lazyfree` deletion causing blocked queries, setting high TTL values leading to memory exhaustion, using `allkeys-lru` eviction causing cache instability, improper `maxmemory-policy` settings leading to frequent key evictions, and high write amplification slowing down replication and persistence. These issues become particularly problematic in large-scale applications where Redis serves as a caching layer or primary data store. This article explores Redis expiry and eviction bottlenecks, debugging techniques, and best practices for optimizing key management.
Common Causes of Redis Latency and Memory Issues
1. Inefficient Key Expiry Leading to Memory Exhaustion
Setting high TTL values without monitoring expiry rates can cause memory bloat.
Problematic Scenario
SET session:user123 "data" EX 86400
Using a high TTL (`EX 86400`) may prevent efficient memory reclamation.
Solution: Optimize Key Expiry Based on Usage Patterns
SET session:user123 "data" EX 3600
Using a shorter TTL (`EX 3600`) ensures faster memory turnover for ephemeral data.
2. High Latency Due to `lazyfree` Blocking Deletions
Using `lazyfree` may cause query blocks when deleting large keys.
Problematic Scenario
UNLINK large-key
If `UNLINK` is not used correctly, large key deletions can block queries.
Solution: Use `UNLINK` to Asynchronously Delete Large Keys
UNLINK session:user123
Using `UNLINK` ensures large keys are deleted asynchronously, preventing query stalls.
3. Frequent Evictions Causing Query Failures
Improper eviction policies lead to frequent cache misses and slow responses.
Problematic Scenario
maxmemory-policy allkeys-lru
Using `allkeys-lru` may evict critical data unpredictably.
Solution: Use `volatile-lru` to Evict Only Expirable Keys
maxmemory-policy volatile-lru
Using `volatile-lru` ensures only keys with TTLs are evicted, preserving persistent data.
4. High Write Amplification Slowing Down Replication
Frequent writes to Redis persistence files (`AOF` or `RDB`) slow down replication.
Problematic Scenario
appendonly yes
appendfsync always
Setting `appendfsync always` causes excessive disk writes, impacting performance.
Solution: Use `appendfsync everysec` to Balance Durability and Performance
appendonly yes
appendfsync everysec
Using `appendfsync everysec` reduces write amplification while maintaining durability.
5. Memory Fragmentation Leading to High Memory Usage
Memory fragmentation causes Redis to allocate more memory than required.
Problematic Scenario
INFO memory
High `mem_fragmentation_ratio` (>1.5) indicates inefficient memory usage.
Solution: Enable Active Defragmentation
config set activedefrag yes
Using `activedefrag yes` optimizes memory allocation, reducing fragmentation.
Best Practices for Optimizing Redis Expiry and Eviction
1. Use Efficient Key Expiry Policies
Set TTL values based on data usage.
Example:
SET session:user123 "data" EX 3600
2. Delete Large Keys Asynchronously
Prevent query stalls using `UNLINK`.
Example:
UNLINK session:user123
3. Optimize Eviction Strategies
Ensure only unnecessary keys are evicted.
Example:
maxmemory-policy volatile-lru
4. Reduce Write Amplification
Optimize persistence settings for better write performance.
Example:
appendfsync everysec
5. Enable Active Memory Defragmentation
Reduce memory fragmentation.
Example:
config set activedefrag yes
Conclusion
Latency spikes and unresponsive queries in Redis often result from inefficient key expiry policies, frequent evictions, excessive write amplification, and high memory fragmentation. By optimizing key expiry, using proper eviction strategies, tuning persistence settings, and enabling active memory defragmentation, developers can significantly improve Redis performance and stability. Regular monitoring using `INFO`, `latency doctor`, and `redis-cli --latency` helps detect and resolve performance issues before they impact production environments.