Redis — OOM command not allowed

Diagnose Redis memory exhaustion by checking maxmemory, eviction policy, large keys, and fragmentation, then choose capacity or eviction deliberately.

intermediatedebuggingredismemory

Symptoms

OOM command not allowed when used memory > 'maxmemory'
Writes fail while reads continue to work
Memory usage sits at the configured maxmemory limit
The error appears after a traffic increase or a new key pattern

Possible causes

maxmemory is reached and the policy is noeviction
A cache instance has no TTLs or an inappropriate eviction policy
A few large keys or a growing list/set dominates memory
Fragmentation or replication buffers consume memory outside the dataset
The capacity was sized for the dataset without headroom for overhead

Diagnosis steps

Read memory usage and limits

redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'

Interpretation

Compare used memory with maxmemory and check fragmentation. A ratio well above 1.5 suggests allocator or workload issues.

Check the eviction policy

redis-cli CONFIG GET maxmemory-policy

Interpretation

noeviction returns OOM errors; allkeys-lru or volatile-lru evicts keys. The policy must match the data's role.

Find large keys and growth patterns

redis-cli --bigkeys

Interpretation

Large lists, sets, or hashes can dominate memory even when the key count looks small.

Root cause

Redis reached the configured memory limit and could not evict or reject the write gracefully. The cause is a capacity, TTL, key-size, or policy mismatch, not a Redis bug.

Fix

For cache data, set an eviction policy and TTLs, remove or split large keys, and add capacity with headroom. For durable data, use noeviction, alert before the limit, and move large or non-cache data elsewhere. Do not remove maxmemory to silence the error.

Risk note

Disabling maxmemory can trigger the host OOM killer or swap, causing latency spikes and data loss. Evicting session or queue keys can log users out or drop work.

Verify the fix

Confirm writes succeed with memory below the limit, verify the policy evicts only cache keys, and load-test to the expected peak with headroom. Monitor used_memory, evicted_keys, and rejected writes.

The policy decides what happens at the limit

Redis enforces maxmemory according to maxmemory-policy. With noeviction, writes that need more memory fail with OOM command not allowed. With an LRU or TTL policy, Redis evicts keys to make room. Neither behavior is universally correct; it depends on whether the data is a cache or a durable store.

redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human'
redis-cli CONFIG GET maxmemory-policy

Separate cache from durable data

Sessions, queues, and locks should not share an instance with a cache that evicts arbitrary keys. Use separate instances or databases with documented policies. A cache can tolerate allkeys-lru; a queue cannot. Give cache keys TTLs so memory is reclaimed even without pressure.

Find the growth

--bigkeys samples the keyspace and reports the largest keys by type. A single large hash or list can consume more memory than thousands of small keys. Split it, expire it, or move it to a store designed for large values. Check mem_fragmentation_ratio; high fragmentation may require a restart or allocator tuning, not just more memory.

Verify with headroom

Set the limit below the host or container limit, load-test to peak, and confirm that cache evictions occur as expected while durable writes do not fail silently. Alert on memory percentage and eviction rate. Removing maxmemory is not a fix; it converts a controlled write error into an unpredictable host failure.