Fixing Redis OOM: 'Command not allowed when used memory > maxmemory'

TL;DR: The 30-Second Fix

Your Redis instance has hit its memory ceiling and is now rejecting all write operations to protect itself. You can restore service immediately by bumping the limit or changing how Redis handles full memory. Run these commands in redis-cli:

# 1. Check how much memory is actually used
INFO memory

# 2. Increase limit to 4GB (example: use 80% of your available system RAM)
CONFIG SET maxmemory 4gb

# 3. Enable automatic deletion of old data to make room
CONFIG SET maxmemory-policy allkeys-lru

This fix works instantly without a restart. To prevent the error from returning after a reboot, remember to update your redis.conf file with these same values.

Why is this happening?

Redis is an in-memory database. Unlike PostgreSQL or MySQL, which can spill over to disk, Redis strictly adheres to the maxmemory limit defined in your config. When you see this error, you've reached that limit.

By default, many Redis installations use the noeviction policy. This means that once the RAM is full, Redis refuses to accept new data rather than deleting old keys. While read commands (like GET or EXISTS) still work perfectly, write commands (SET, HSET, LPUSH) will fail with the OOM error.

Keep an eye on mem_fragmentation_ratio. If this number is above 1.5, Redis might be holding onto memory that it isn't actually using for data, making the system feel "full" earlier than expected.

Proven Fixes

1. Expand the Memory Ceiling

If your server has spare RAM, the easiest path is to give Redis more room. If you are running on a 16GB VPS and Redis is capped at 2GB, you have plenty of overhead.

redis-cli
> CONFIG GET maxmemory
> CONFIG SET maxmemory 8gb

A word of caution: Avoid setting maxmemory 0 (unlimited) on production servers. If Redis consumes all physical RAM, the Linux OOM Killer will likely panic and kill the Redis process entirely, leading to total downtime.

2. Automate Data Cleanup (Eviction)

In most caching scenarios, you don't need to keep every key forever. You can tell Redis to act like a smart cache by deleting old or underused data when it hits the limit.

Update your redis.conf or use CONFIG SET to choose a policy:

• allkeys-lru: Removes the least recently used keys. This is the gold standard for most web applications.
• volatile-ttl: Only removes keys that have an expiration (TTL) set, prioritizing those about to expire.
• allkeys-lfu: Removes the least frequently used keys (useful if some data is accessed 1,000x more than others).

3. Fix Background Save Failures (Overcommit Memory)

Sometimes you have enough RAM, but Redis still triggers an OOM error during a BGSAVE (disk snapshot). This happens because Linux is too conservative about memory allocation when Redis tries to fork a child process.

To fix this, allow the kernel to "overcommit" memory by running this as root:

sysctl vm.overcommit_memory=1

Add vm.overcommit_memory = 1 to /etc/sysctl.conf to make it stick after a reboot. This ensures Redis can save data to disk even when memory usage is high.

4. Hunt Down "Big Keys"

One single massive hash or list can often be the culprit. A single key containing a 500MB JSON blob is a ticking time bomb for memory management. Use the built-in scanner to find them:

# This scans the entire keyspace without blocking the server
redis-cli --bigkeys

If you find a list with 1,000,000 elements that you only need for 24 hours, apply a TTL: EXPIRE my_massive_list 86400.

Confirming the Fix

Don't just walk away once the error stops. Verify the health of your instance with these steps:

• Check the gap: Run INFO memory and compare used_memory_human against maxmemory_human. You want a comfortable buffer.
• Verify writes: Run SET health_check 1. If it returns OK, your application is back in business.
• Watch evictions: If you enabled an eviction policy, run redis-cli info stats | grep evicted_keys. If this number is climbing, Redis is successfully making room for new data.