Redis Memory and Eviction
Redis keeps all data in RAM, and RAM is limited. A memory limit protects the server from running out of space, and an eviction policy tells Redis which keys to remove when the limit arrives. Understanding both settings prevents sudden crashes and surprise errors.
The Wardrobe Analogy
A wardrobe holds a fixed number of clothes. When you buy a new shirt and the wardrobe is full, you must give something away. You might remove the oldest item, the least worn item, or a random one. Redis faces the same choice, and the eviction policy sets the rule.
Memory limit reached
┌───────────────────────────┐
│ [A][B][C][D][E][F][G][H] │ ← full
└───────────────────────────┘
│ new key I arrives
▼
Policy picks a victim, for example C
┌───────────────────────────┐
│ [A][B][I][D][E][F][G][H] │
└───────────────────────────┘
Setting the Memory Limit
127.0.0.1:6379> CONFIG SET maxmemory 256mb OK 127.0.0.1:6379> CONFIG SET maxmemory-policy allkeys-lru OK
A maxmemory value of 0 removes the limit. On a 64-bit server, Redis then grows until the operating system steps in.
The Eviction Policies
Policy Removes Best Use ───────────────── ──────────────────────────────────────── ────────────────── noeviction Nothing. Writes fail with an error Primary data store allkeys-lru Least recently used key from all keys General cache allkeys-lfu Least frequently used key from all keys Cache with hot items allkeys-random Random key from all keys Even access patterns volatile-lru Least recently used key with a TTL Mixed cache and data volatile-lfu Least frequently used key with a TTL Mixed cache and data volatile-random Random key with a TTL Mixed cache and data volatile-ttl Key with the shortest remaining TTL Time-driven data
LRU and LFU in Plain Words
LRU stands for Least Recently Used. It removes the key that nobody touched for the longest time. LFU stands for Least Frequently Used. It removes the key that people touched the fewest times overall. LFU protects a popular item that was quiet for a short moment.
Volatile Policies
Volatile policies pick victims only among keys that carry an expiry time. When no such keys exist, writes fail as if the policy were noeviction.
What Happens with noeviction
127.0.0.1:6379> SET news:99 "Breaking story" (error) OOM command not allowed when used memory > 'maxmemory'.
Redis refuses new writes but keeps serving reads. This safe behavior suits servers that hold data you cannot afford to lose.
Checking Memory Use
127.0.0.1:6379> INFO memory used_memory_human:182.40M maxmemory_human:256.00M mem_fragmentation_ratio:1.12 127.0.0.1:6379> MEMORY USAGE user:1001 (integer) 232
MEMORY USAGE reports the bytes one key consumes. The fragmentation ratio compares memory the operating system gave Redis against memory Redis actually uses. A ratio near 1.0 to 1.5 is healthy. A ratio far above 1.5 signals wasted space.
Practical Example – Product Cache
Situation: An online shop caches product pages in Redis.
The cache can be rebuilt from the database at any time.
Settings:
maxmemory 2gb
maxmemory-policy allkeys-lfu
Result:
Popular products stay in memory.
Rarely viewed products leave when space runs short.
Customers never see an error.
Choosing the Right Policy
- Pick allkeys-lru or allkeys-lfu when Redis serves only as a cache.
- Pick noeviction when Redis holds the single copy of important data.
- Pick a volatile policy when one server holds both cache keys with TTLs and permanent keys.
Key Points
- maxmemory caps the memory Redis uses for data.
- The eviction policy decides which keys leave when the cap arrives.
- noeviction rejects writes, while allkeys policies remove old keys.
- INFO memory and MEMORY USAGE show where memory goes.
- Reserve extra system RAM for replication buffers and snapshots.
