Redis maxmemory: choose eviction behavior by the meaning of each key

Last updated: 5 Oct 20267 min read

tutorial

Redis maxmemory limits dataset growth under a selected eviction policy. With noeviction, writes that need more memory can fail while reads of existing keys continue. With an all-keys policy, Redis may remove cached keys to make room, shifting load toward the backing service. Policies restricted to expiring keys have a narrower candidate set; if too few keys qualify, writes can fail even though non-expiring keys occupy memory. The setting does not make every process allocation fit inside the dataset limit. Replication buffers, clients, allocator fragmentation, and persistence work also need memory headroom at the host or container boundary.

Operational decision

A product catalog cache stores 2.3 million regenerable entries and shares the Redis instance with a small set of session tokens. Mixing the two makes allkeys eviction unsafe for sessions, while noeviction can turn a catalog traffic spike into write errors. Split the workloads or move session authority elsewhere. For the catalog cache, set a measured maxmemory budget and an all-keys eviction policy, then load 34 percent above the expected working set. Track evicted keys, hit ratio, miss latency, source-database QPS, resident memory, and rejected commands. Protect the backing database with bounded refill concurrency. A high hit ratio measured before eviction begins is not evidence that overload behavior is safe.

Catalog: regenerable keys on dedicated cache
Session token authority: separate store
Load test: 134% of forecast working set
Observe: evictions, write errors, p99 miss latency, source QPS
Abort: database refill exceeds its safe connection budget

Cost and verification

A larger memory limit buys a larger working set but increases failover transfer, snapshot size, and per-node cost. An eviction policy trades write availability for miss amplification; poor key-size distribution can make either outcome abrupt. Set alerts on used memory and resident memory separately, and include non-dataset allocations in the container limit. If a failed write affects business state, Redis should not be treated as an expendable cache. Rehearse a failover while near the limit, because replica promotion and persistence can consume additional headroom.

Common Mistakes

Do not share evictable catalog data with authoritative session state under one policy.
Do not assume maxmemory equals total process memory.
Do not celebrate eviction without checking database refill pressure.

Connected lessons

Practice and check

devops

redis

data-operations