Understanding Redis maxmemory Configuration and Approximate LRU Eviction Policies

Redis, a popular in‑memory cache, uses the maxmemory configuration to cap the amount of memory a server may allocate; setting it to 0 disables the limit (default on 64‑bit systems).

When the limit is reached, Redis selects an eviction policy via the maxmemory‑policy option. Available policies include:

noeviction – refuse new writes and return an error.

allkeys‑lru – evict the least‑recently used key among all keys.

volatile‑lru – evict the least‑recently used key among keys with an explicit TTL.

allkeys‑random – evict a random key.

volatile‑random – evict a random key with a TTL.

volatile‑ttl – evict the key that is closest to expiration.

Choosing the right policy depends on the application’s access pattern; for power‑law workloads allkeys‑lru is often a safe default, while uniform access may benefit from allkeys‑random , and TTL‑driven cleanup can use volatile‑ttl .

Redis implements an approximate LRU algorithm: it samples a small number of keys (controlled by maxmemory‑samples ) and evicts the sampled key with the oldest access time. Since Redis 3.0 the algorithm maintains a candidate pool, improving accuracy. Example configuration:

maxmemory 100mb

maxmemory‑samples 5

The approximation trades a modest amount of memory and CPU for near‑LRU behavior, which is sufficient for most caching scenarios. Administrators can adjust the sample size to balance precision against overhead, and monitor hit/miss ratios via INFO to fine‑tune settings.