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

The ErrorRedis is designed to be fast by keeping everything in RAM. But when that RAM fills up, the party stops. If you see this error, your application has tried to write data to a Redis instance that is already at its 'hard ceiling'.

(error) OOM command not allowed when used memory > 'maxmemory'

Essentially, Redis has hit the maxmemory limit defined in your config, and your current settings don't allow it to delete old data to make room for the new. As a safety measure, it goes into a read-only mode for most commands.

Immediate DiagnosisWhen my logs start blowing up with OOM errors, I check the memory breakdown immediately. Connect to your instance and run:

redis-cli info memory

Focus on these three metrics:

• used_memory_human: The actual data size (e.g., 1.95G).- maxmemory_human: Your configured limit (e.g., 2.00G).- maxmemory_policy: This is usually the culprit.If your policy is set to noeviction, Redis will never delete keys automatically. It will simply reject every new write until you manually clear space or increase the limit.

Step-by-Step Fix### 1. Quick Relief: Bump the LimitIf your server has physical RAM to spare—for example, a 4GB VPS only using 2GB—you can instantly resume service by raising the limit. This change happens in real-time without a restart:

# Increase to 3 Gigabytes
redis-cli config set maxmemory 3gb

Verify the new limit is active:

redis-cli config get maxmemory

2. Automate Data Cleanup (Eviction Policy)Increasing RAM is a temporary fix. For a sustainable setup, you need an eviction policy that removes old data when the bucket gets full. For most caching use cases, allkeys-lru is the standard choice because it removes the least recently used keys first.

redis-cli config set maxmemory-policy allkeys-lru

Here is what the common policies actually do:

• allkeys-lru: Discards the oldest, least-used keys to make room. Best for most caches.- volatile-lru: Only removes keys that have an expiration (TTL) set. Dangerous if you forgot to set TTLs.- allkeys-random: Just picks keys to delete at random. Use this only if data age doesn't matter.### 3. Make the Fix PermanentDon't forget that redis-cli changes vanish if the server reboots. You must update your configuration file, typically located at /etc/redis/redis.conf.

sudo nano /etc/redis/redis.conf

# Find these lines and update them:
maxmemory 3gb
maxmemory-policy allkeys-lru

Save the file. Since you already applied the changes via the CLI, you don't need to restart the service now.

4. Hunt Down Memory HogsSometimes the issue isn't a small limit, but one giant key. The --bigkeys tool scans your database to find the largest strings, lists, or sets. It uses the SCAN command, so it shouldn't block your server, but run it during low-traffic periods just in case.

redis-cli --bigkeys

If you see a single 'Set' with 5 million members, you've found your leak.

VerificationCheck if the write-lock is lifted by setting a test key:

redis-cli set health_check "ok"

If you see OK, your application can write again. I usually follow this up by monitoring the memory trend for 60 seconds:

redis-cli --interval 1 --stat

Preventive Strategies- Set TTLs on everything: Unless data is critical, give it an expiration date. This prevents Redis from becoming a graveyard of forgotten data.- The 80% Rule: Configure your monitoring system to alert you when used_memory hits 80% of maxmemory. This gives you a buffer to react before the OOM error hits.- Fragment Check: If used_memory_rss is significantly higher than used_memory, your memory is fragmented. On Redis 4.0+, you can try CONFIG SET activedefrag yes to clean it up in the background.