Configure Redis Memory and Eviction Policy

Set a memory ceiling and an eviction policy that matches the data's role, monitor evictions, and prevent Redis from silently deleting queues or sessions.

~25 minrediscachingoperations

Task

Keep Redis within its memory budget while ensuring cache keys can be evicted and durable data cannot disappear without an alert.

When to use this

Redis runs without a maxmemory limit, the host runs out of memory, and the kernel kills the process or the cache silently evicts keys that were treated as durable.

Prerequisites

A Redis 7+ instance with a known memory budget
A clear classification of keys as cache, session, queue, or primary data
Access to redis-cli and monitoring for memory and evictions

Steps

1. Set maxmemory below the host or container limit, leaving headroom for fragmentation and connections.

redis-cli CONFIG SET maxmemory 512mb

Expected output: INFO memory shows maxmemory 512mb and used_memory below the limit.

2. Choose an eviction policy for cache-only data; use noeviction for data that must not vanish.

redis-cli CONFIG SET maxmemory-policy allkeys-lru

Expected output: Cache keys are evicted under pressure instead of the process being killed.

3. Monitor evicted keys, memory fragmentation, and rejected writes to confirm the policy behaves as intended.

redis-cli INFO stats | grep -E 'evicted_keys|rejected_connections' && redis-cli INFO memory | grep used_memory

Expected output: Evictions appear only for cache keys, and durable writes are not silently lost.

4. Give cache keys explicit TTLs and test the behavior under a synthetic memory fill in a non-production instance.

redis-cli CONFIG GET maxmemory-policy

Expected output: The policy is persisted in configuration and the test confirms the expected eviction or error behavior.

Troubleshooting

Problem

Redis refuses writes after reaching maxmemory

Solution

The policy is noeviction. That is correct for durable data; move cache data to a separate instance or increase capacity.

Problem

Sessions disappear under load

Solution

Session keys are being evicted. Use a separate Redis instance or database for sessions, or make the application tolerate re-authentication.

Limitations

allkeys-lru approximates recency and can evict a hot key that has not been accessed recently.
Redis eviction is not a substitute for capacity planning or for durable storage of critical records.

Decide what may disappear

An eviction policy is a data-loss policy. Cache responses, rendered fragments, and rate-limit counters can be recreated. Queues, locks, and session records may not be. Mixing both in one instance forces a single policy on incompatible data. Use separate instances or at least separate databases with documented ownership, and set maxmemory on each.

redis-cli CONFIG SET maxmemory 512mb
redis-cli CONFIG SET maxmemory-policy allkeys-lru
redis-cli INFO memory

allkeys-lru evicts any key to make room; volatile-lru only evicts keys with a TTL. noeviction returns an error when memory is full, which is safer for durable data but turns a memory problem into write failures. Choose deliberately and record the decision.

Leave headroom

Set the limit below the container or host limit so fragmentation, replication buffers, and client connections do not trigger the OOM killer. Monitor used_memory, mem_fragmentation_ratio, and evicted_keys. A sudden eviction spike means the cache is undersized or a workload changed. A rising fragmentation ratio may justify a restart or a different allocator, not a larger limit by itself.

Make eviction visible

Alert when evictions exceed a threshold for cache instances and when writes fail for durable instances. Log the policy and limit at startup so an environment drift is visible. Test the behavior by filling a non-production instance to the limit; confirm that cache keys are evicted and durable keys either remain or produce the expected error. A policy that is only documented, never exercised, is a guess.