allkeys-lru vs allkeys-lfu for high-churn workloads

Eviction Policy Trade-offs

When Redis reaches its maxmemory limit, the choice of eviction policy determines which data is purged to accommodate new writes. For workloads where memory is the primary binding constraint, two primary documented approaches exist for the entire keyspace: allkeys-lru and allkeys-lfu.

Recency vs Frequency

The allkeys-lru policy is designed for patterns where the most recently accessed data is the most likely to be reused. Conversely, allkeys-lfu (introduced in Redis 4.0) targets workloads with a stable "hot set" that must be protected from being flushed by a sudden burst of one-off keys that would otherwise appear "recent" to an LRU algorithm.

Sampling and CPU Overhead

Redis implements these policies approximately by sampling a subset of keys defined by maxmemory-samples. Increasing this value improves the accuracy of the eviction candidate but increases CPU utilization during write operations under memory pressure.

Given a workload with a mix of long-term hot keys and high-frequency short-lived keys:

• How should the lfu-decay-time be calibrated to prevent legacy hot keys from blocking new high-frequency data?
• At what threshold does the CPU cost of increasing maxmemory-samples outweigh the gain in cache hit ratio?