Configuring Redis Eviction for a Bounded Cache: Maxmemory, Policy, and Verification

Problem and Goal

Running Redis as a cache often means you want the instance to stay within a fixed memory envelope. Without a limit, a burst of writes can trigger an out‑of‑memory (OOM) kill. With a limit but the wrong eviction policy, Redis may refuse writes instead of discarding old keys, which can break application logic. The goal is to configure Redis so that it never exceeds a chosen memory cap, automatically evicts keys according to a predictable strategy, and keeps replicas in sync.

Prerequisites

• Redis 4.0+ (LFU policy and some config options require it). Verify with redis-cli INFO server | grep redis_version.
• Root or sudo access to edit redis.conf or run CONFIG SET commands.
• Knowledge of the machine’s physical RAM and the workload’s memory footprint.
• Optional: persistence enabled (RDB/AOF) or an understanding of replication buffers.

Step 1 – Choose a Memory Cap

Typical practice is to set maxmemory to 70–80 % of the host’s RAM. The remaining 20–30 % provides headroom for:

• Redis’s internal fragmentation.
• Replication buffers and network I/O.
• Fork‑based persistence (BGSAVE/AOF rewrite can spike RSS).

Calculate the value in bytes. For example, on a machine with 16 GB RAM, 80 % is 12.8 GB (13,824,000,000 bytes). In redis.conf you would write:

maxmemory 13824000000

Or set it at runtime:

CONFIG SET maxmemory 13824000000

Step 2 – Pick an Eviction Policy

Redis offers several policies. For a pure cache, allkeys-lru or allkeys-lfu are common. The difference:

• allkeys-lru evicts the least‑recently used key across the entire dataset.
• allkeys-lfu evicts the least‑frequently used key; this preserves hot keys under heavy scan workloads.

If you only want to evict keys that have a TTL, use volatile-ttl or volatile-lru. However, if no keys have a TTL, these policies act like noeviction and will return an error on writes that exceed the limit.

Set the policy in redis.conf:

maxmemory-policy allkeys-lru

Or at runtime:

CONFIG SET maxmemory-policy allkeys-lru

Step 3 – Tune Sample Size (Optional)

Eviction is approximate: Redis samples maxmemory-samples keys (default 5) to pick the best candidate. Increasing this number improves accuracy but adds CPU overhead.

maxmemory-samples 10

Step 4 – Apply and Restart

After editing redis.conf, restart the service (e.g., systemctl restart redis) or apply changes via CONFIG SET. Verify the live settings:

redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy

Step 5 – Verify Eviction Is Working

Insert keys until the memory cap is reached. Use a script or redis-benchmark:

redis-benchmark -n 1000000 -d 1024 -t set

Then inspect INFO memory:

redis-cli INFO memory | grep used_memory
redis-cli INFO memory | grep evicted_keys
redis-cli INFO memory | grep mem_fragmentation_ratio

Expected results:

• used_memory stays near maxmemory (e.g., maxmemory: 13824000000, used_memory: 13790000000).
• evicted_keys increases as new writes trigger eviction.
• Fragmentation ratio should be <1.5; higher values indicate excessive memory pressure.

To confirm hot keys survive, run redis-cli --bigkeys or MEMORY USAGE key on frequently accessed keys before and after a burst of writes.

Step 6 – Monitor and Adjust

Continuous monitoring is essential. Add alerts for:

• evicted_keys > 0 (indicates eviction is happening).
• Fragmentation ratio > 1.5.
• High used_memory_peak relative to maxmemory.

If you observe that no eviction occurs, check that:

• The policy is allkeys-* and not volatile-* when you have no TTL keys.
• Keys actually exceed maxmemory (use INFO memory to confirm).
• Persistence or replication buffers are not consuming a large part of the cap.

Recovery Options

• No Eviction Detected: Switch to allkeys-lru or allkeys-lfu if you were using volatile-*.
• Too Many Evictions: Increase maxmemory or reduce maxmemory-samples to make eviction decisions faster.
• High Fragmentation: Run MEMORY PURGE (Redis 7.0+) or restart the instance after a BGSAVE to reduce RSS. Alternatively, increase physical RAM.
• Remember that changing maxmemory or policy does not roll back automatically; you must re‑apply the configuration.

Limitations and Caveats

• Eviction decisions are approximate; the policy does not guarantee exact LRU order.
• Mixing persistent data with cache data in the same instance can cause silent eviction of durable keys if allkeys-* is used.
• Fragmentation can still lead to OOM if the RSS grows far beyond used_memory; monitor mem_fragmentation_ratio.
• LFU and some config options require Redis 4.0+; verify your version before applying.

Concrete Example – A Minimal redis.conf Snippet

# Memory limits
maxmemory 13824000000
maxmemory-policy allkeys-lru
maxmemory-samples 10

# Persistence (optional)
save 900 1
save 300 10
appendonly no

After saving, restart Redis and run the verification steps above. Keep the INFO memory output in a log for trend analysis.

Conclusion

By setting maxmemory to a safe percentage of host RAM, selecting an appropriate eviction policy, and rigorously verifying eviction behavior, you can run Redis as a bounded cache that tolerates traffic spikes without crashing. Monitor key metrics, adjust as needed, and avoid mixing persistent and cache data in the same instance to keep the system predictable.