Fix Redis eviction policy misconfiguration | Cache eviction fix

You get this error when your Redis server runs out of memory and the eviction policy starts deleting keys you didn't expect to lose. The exact moment: your app suddenly slows down, you see OOM command not allowed when used memory > 'maxmemory' in logs, and your cache hit rate drops to near zero. I've seen this on Redis 6.x and 7.x, usually on servers with 4GB or 8GB maxmemory set. The trigger is almost always a default config that uses allkeys-lru or noeviction.

What's actually happening

Redis has a memory limit (maxmemory). When it hits that limit, it needs to evict some keys. The eviction policy decides which keys get the boot. The default? noeviction. That means Redis just returns errors when memory is full. But a lot of people change it to allkeys-lru thinking it's safe. It's not. allkeys-lru evicts any key — even your important ones that never expire. You lose session data, user permissions, config values. The application then tries to fetch them from the database, which kills performance.

The real fix is to use volatile-lru or allkeys-lfu depending on your use case. Let me walk you through it.

The fix: change the eviction policy

Do not restart Redis yet. First, check what policy you're using and what keys you have. Then apply the fix live, no downtime.

Check current config
Run this on the Redis CLI:
```
redis-cli CONFIG GET maxmemory-policy
```
If it shows noeviction or allkeys-lru, you're in trouble.
Check maxmemory setting
```
redis-cli CONFIG GET maxmemory
```
Should be > 0 and reasonable for your workload (like 4GB or 8GB). If it's 0, that's unlimited — bad for production.
Set a better policy live
For most apps, volatile-lru is the sweet spot. It evicts only keys that have a TTL set. Your permanent keys stay safe.
```
redis-cli CONFIG SET maxmemory-policy volatile-lru
```
No restart needed.
Set maxmemory if it's 0
```
redis-cli CONFIG SET maxmemory 4gb
```
Adjust the size to 75% of your server's RAM, leaving some for the OS.
Make it permanent
Edit /etc/redis/redis.conf or your config file:
```
maxmemory 4gb
maxmemory-policy volatile-lru
```
Then restart Redis during a maintenance window:
```
systemctl restart redis
```
Or service redis-server restart on older systems.

Which policy should you pick?

Here's my take based on what I see in production:

volatile-lru — Use this if you have a mix of TTL keys (like cached DB results) and permanent keys (like config). It evicts the least recently used TTL keys. Best for most web apps.
allkeys-lfu — Use this if all your keys are temporary and you want to keep the most frequently used ones. Good for caching heavy queries where usage patterns are stable.
volatile-ttl — Only if you're sure about your TTL values. It evicts keys with the shortest TTL first. Risky if TTLs are set wrong.
noeviction — Never use this in production unless you have a separate monitoring system that keeps memory under control. I've seen it cause cascading failures.
allkeys-lru — Avoid. It's a trap. It evicts your permanent keys too.

Still failing? Check these

If the error persists after changing the policy, don't panic. Here are the usual suspects:

Your keyspace is too big — Run redis-cli INFO keyspace and check db0:keys. If you have millions of keys, even a good eviction policy can't save you. You need to reduce TTLs or add sharding.
That config change didn't stick — Verify with redis-cli CONFIG GET maxmemory-policy. If it's still the old value, you might have a read-only config or another config file overriding it.
You have a memory leak in your app — Check if your application is creating keys without expiration. Use redis-cli --bigkeys to spot huge keys or tons of small ones. Fix the code.
Your maxmemory is too small — If you set it too low (e.g., 1GB when your dataset is 3GB), even the best policy can't keep up. Monitor evicted_keys in INFO stats. If that number keeps climbing, raise maxmemory.

I've seen this exact problem bring down e-commerce sites during Black Friday. The fix is simple: get off allkeys-lru or noeviction and use volatile-lru. Test it on a staging server first. You'll thank me later.