Lazyfree-lazy-eviction configured with allkeys-lru policy

Question

When using Redis with the lazyfree-lazy-eviction option enabled, the server attempts to evict keys asynchronously to reduce latency spikes during memory pressure. The interaction of this setting with the allkeys-lru eviction policy is not fully documented, leaving administrators unsure whether asynchronous eviction provides the same latency guarantees as the synchronous LRU eviction that occurs when lazyfree-lazy-eviction is disabled.
The goal is to understand if enabling lazyfree-lazy-eviction under allkeys-lru still ensures that eviction decisions are made off the main thread without blocking command processing, and whether any edge cases could cause delayed reclamation or temporary memory growth under heavy write loads.
Specifically:

Does lazyfree-lazy-eviction guarantee that eviction of LRU‑selected keys happens asynchronously when the policy is allkeys-lru?
Are there any workload patterns (e.g., high‑frequency updates with short TTLs) where async eviction under allkeys-lru could still produce latency spikes?
Which Redis versions first document or guarantee this behavior?

Tasadduq Burney · Answer

Answer
When lazyfree-lazy-eviction is set to yes and the maxmemory-policy is allkeys-lru, Redis still performs the LRU candidate selection on the main thread, but the actual memory deallocation of the chosen key is handed to a background lazyfree thread. This guarantees that the command processing path is never blocked by the free operation, while the eviction decision remains deterministic.
Guaranteed asynchronous behaviour

Selection of the least‑recently‑used key happens synchronously as part of the normal eviction logic.
If lazyfree-lazy-eviction is enabled, the key is queued for the lazyfree thread; the main thread immediately continues.
Command latency is therefore not directly affected by the free operation.

When latency spikes can still appear

High‑frequency writes that create many short‑TTL keys can keep the lazyfree queue full, causing lazyfree_pending_objects to grow. While the queue is full, the memory used by evicted keys is retained, so used_memory may stay above the threshold and trigger another eviction cycle, briefly increasing latency.
Bursty workloads that exceed the background thread’s capacity can temporarily defer reclamation. The main thread remains non‑blocking, but the delayed free may lead to a short latency spike when the queue finally drains.

Version history
The lazyfree-lazy-eviction directive was introduced in Redis 4.0 (released 2018). The documented behaviour described above applies to Redis 4.0 and later. Earlier releases do not support lazyfree.
Verification steps

Confirm the settings:
CONFIG GET lazyfree-lazy-eviction
CONFIG GET maxmemory-policy

Observe eviction activity:
INFO memory
# look for evicted_keys and lazyfree_pending_objects

Monitor latency:
LATENCY DOCTOR

Check that spikes diminish when the memory limit is hit under this configuration.

Lazyfree-lazy-eviction configured with allkeys-lru policy

1 answer

0 question comments

Answer

Guaranteed asynchronous behaviour

When latency spikes can still appear

Version history

Verification steps

Your perspective belongs here.