Redis Memory Management

Redis holds everything in memory, so memory policy is the most consequential configuration decision you make.

maxmemory

maxmemory 12gb
maxmemory-policy allkeys-lru

Set it below the container or host memory limit, not equal to it. Redis needs headroom for replication buffers, client output buffers, and the copy-on-write growth during a background save. Leaving roughly 20–30% headroom is a common starting point; the right number depends on your write rate and persistence configuration.

Eviction Policies

When memory reaches maxmemory, the policy decides what happens.

Choosing:

• Pure cache → allkeys-lru, or allkeys-lfu when access is skewed and you want to keep genuinely hot keys rather than merely recent ones.
• Mixed cache and data that must not disappear → volatile-lru, with TTLs on the cache entries only. But note the failure mode below.
• Data that must never be evicted → noeviction, and accept that writes fail when full. That must be a monitored, alerted condition.

Redis's LRU and LFU are approximations sampled from a few keys per eviction. maxmemory-samples 5 is the default; raising it improves accuracy at some CPU cost.

Reading memory usage

INFO memory

• used_memory — what Redis believes it is using.
• used_memory_rss — what the OS has allocated to the process.
• mem_fragmentation_ratio — rss / used_memory.
• maxmemory_policy — confirm it is what you configured.
• evicted_keys, expired_keys — cumulative counters worth graphing.

Interpreting the fragmentation ratio:

• Slightly above 1.0 — normal allocator overhead.
• Well above 1.0 — real fragmentation, common after large deletions or many differently sized values. Activefrag (activedefrag yes) can reclaim it gradually at some CPU cost.
• Below 1.0 — part of the dataset has been swapped to disk. This is the worst case for latency and should be treated as an incident.

Finding what uses the memory

MEMORY USAGE shop:user:1001         # bytes for one key, including overhead
MEMORY DOCTOR                        # heuristic advice

# Sampled scan for large keys; safe to run against production.
redis-cli --bigkeys
 
# Precise memory usage per key pattern, at higher cost.
redis-cli --memkeys

--bigkeys uses SCAN and reports the largest key per type. See Big Keys.

Growth without new keys

If used_memory rises while the key count does not, the usual causes are:

• Collections growing inside existing keys — a list or sorted set that nothing trims.
• Client output buffers, especially with pub/sub subscribers that cannot keep up (client-output-buffer-limit).
• Replication backlog sizing (repl-backlog-size).
• Fragmentation after a bulk deletion.

INFO clients and CLIENT LIST show buffer sizes per client, which identifies the pub/sub case quickly.