Home / Databases / Redis

DatabasesTroubleshootingIntermediate

Redis out of memory: OOM errors, evictions and big keys

Read INFO memory, choose the right maxmemory-policy, find big keys and missing TTLs, and handle fragmentation on self-managed and managed Redis.

Deepak Bhardwaj2 min read

Applies toRedis 6/7, Valkey, Amazon ElastiCache, Azure Cache for Redis / Azure Managed Redis, OCI Cache

The error

OOM command not allowed when used memory > 'maxmemory'.

Writes fail but reads still work. With a cache, the app usually falls back to the database, which then becomes slow too.

1. Look at memory

redis-cli INFO memory | egrep "used_memory_human|maxmemory_human|maxmemory_policy|mem_fragmentation_ratio"
redis-cli INFO stats  | egrep "evicted_keys|expired_keys"
redis-cli INFO keyspace

2. Eviction policy

maxmemory-policy Behaviour Use for
noeviction Reject writes when full (the OOM error) Data you can't lose (queues, sessions without a backup)
allkeys-lru / allkeys-lfu Evict least recently / least frequently used keys Pure caches
volatile-lru / volatile-ttl Evict only keys with a TTL Mixed cache and permanent data 
redis-cli CONFIG SET maxmemory-policy allkeys-lru

On ElastiCache and Azure, change it in the parameter group or Advanced settings.

Note

With volatile-* policies, keys without a TTL are never evicted. If the app forgets TTLs, memory fills up anyway.

3. Find what uses the memory

redis-cli --bigkeys           # largest key per type (scans with SCAN, safe-ish)
redis-cli --memkeys           # Redis 7+: by memory usage
redis-cli MEMORY USAGE session:12345

Check keys without TTL on a sample:

redis-cli --scan --pattern 'cache:*' | head -1000 | while read k; do echo "$(redis-cli TTL "$k") $k"; done | grep '^-1 ' | head

Warning

Never run KEYS * on production. It blocks Redis while it walks every key. Use SCAN (--scan).

4. Fragmentation

mem_fragmentation_ratio well above 1.5 → memory is allocated but not used efficiently, often after many deletes.

redis-cli CONFIG SET activedefrag yes

Below 1.0 means Redis memory is being swapped. That's very slow; add memory or reduce data.

5. Leave room for overhead

Forks for RDB snapshots and AOF rewrites use copy-on-write memory. On managed services, reserve memory for this (ElastiCache reserved-memory-percent, Azure maxmemory-reserved / maxfragmentationmemory-reserved). A cache at 95% can fail during the snapshot even if normal use fits.

6. Scale

  • Scale up the node size, or
  • Shard with Redis Cluster (cluster mode on ElastiCache, clustering on Azure Premium/Enterprise).

Tip

Make TTLs mandatory in the cache client wrapper (every SET must pass an expiry), and alert on evicted_keys rising quickly. Some eviction is normal for a cache; a sudden jump means the working set no longer fits.

Related fixes