Fix: OOM command not allowed when used memory > 'maxmemory'

Redis returns OOM command not allowed when used memory > 'maxmemory' when its memory usage has crossed the configured maxmemory limit and the eviction policy is noeviction, so it refuses any command that could allocate more memory. Reads keep working, but every write fails, which usually means sessions stop saving, queues stop accepting jobs, and caches stop filling. The immediate fix is fast. The real work is deciding whether this Redis should evict, grow, or hold less data.

What this error means

Redis enforces maxmemory as a hard budget on used_memory, the amount tracked by its own allocator. When usage exceeds the budget, behavior depends on maxmemory-policy. With noeviction, the default, Redis rejects commands that may grow memory (SET, LPUSH, HSET, EXPIRE, and most writes) with this exact error while still serving reads and deletes:

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

With any eviction policy (allkeys-lru, volatile-lru, allkeys-lfu, and so on), Redis instead frees keys to stay under the limit and you rarely see this error, though under volatile-* policies it still appears if there are no keys with a TTL left to evict.

Note that used_memory includes more than your keys. Replication backlogs, client output buffers, and Lua or function memory all count toward the limit, so a slow replica or a client draining a huge response can push a healthy dataset over the edge.

Common causes

• maxmemory is set with the default noeviction policy on an instance used as a cache, so nothing ever gets evicted and it fills up.
• Genuine data growth: keys written without TTLs accumulate until the dataset exceeds the budget.
• A few huge keys (a hash or sorted set that grew unbounded, a list used as a queue that no consumer drains).
• Memory fragmentation: used_memory_rss far above used_memory after churn, which wastes the host’s RAM even though the OOM check itself uses used_memory.
• maxmemory set too close to physical RAM, leaving no headroom for the fork that BGSAVE and AOF rewrite create. Copy-on-write during the fork can spike the resident size sharply, and operators respond by lowering maxmemory, which then triggers this error under normal load.
• Replication or client output buffers ballooning (a stuck replica, a client running KEYS or a huge LRANGE) and counting against the limit.

How to fix it

STABILIZE first. Writes are failing, so buy room immediately, then diagnose.

1. Check where you stand.

redis-cli INFO memory

Read used_memory_human, maxmemory_human, maxmemory_policy, mem_fragmentation_ratio, and used_memory_rss_human.

2. If this Redis is a cache, switch the policy so Redis frees memory itself. This takes effect instantly.

redis-cli CONFIG SET maxmemory-policy allkeys-lru

3. If it holds real data you cannot evict, raise the limit temporarily, provided the host has free RAM to back it.

redis-cli CONFIG SET maxmemory 6gb

Either change unblocks writes within seconds. Persist whatever you keep:

redis-cli CONFIG REWRITE

DIAGNOSE. Find out what is actually eating the memory.

redis-cli MEMORY DOCTOR
redis-cli --bigkeys
redis-cli MEMORY USAGE <key-name>
redis-cli INFO keyspace

MEMORY DOCTOR flags fragmentation and oversized client buffers. The bigkeys scan samples the keyspace and reports the largest key per type; a single list or hash holding a large share of the budget points at an application bug, not a sizing problem. Check INFO keyspace for the expires count per database: if it is near zero on a cache, keys are being written without TTLs and nothing can ever leave. Also check INFO clients and INFO replication for abnormal buffer usage from a lagging replica or a greedy client.

If mem_fragmentation_ratio is above roughly 1.5, the allocator is holding freed pages. On Redis with jemalloc (the default on Linux) enable active defragmentation:

redis-cli CONFIG SET activedefrag yes

FIX. Match the policy to the workload and size the limit with headroom.

If it is a pure cache: keep allkeys-lru (or allkeys-lfu when a small hot set dominates), make the application set TTLs on every write, and size maxmemory to the working set you actually want cached.

maxmemory 4gb
maxmemory-policy allkeys-lru

If it stores data you cannot lose (queues, sessions, locks): noeviction is the correct policy, and this error is your capacity alarm. Trim the data (cap queue length, expire stale sessions, fix the producer that outruns its consumer) or scale the instance up or out.

In both cases, leave fork headroom. During BGSAVE or AOF rewrite the forked child shares pages copy-on-write, and under heavy writes the resident size can approach double used_memory. On a dedicated host, keep maxmemory at 50 to 65 percent of RAM if you persist to disk. On ElastiCache, keep reserved-memory-percent at 25 for the same reason.

How to prevent it

• Set an explicit maxmemory and a deliberate maxmemory-policy on every instance; never rely on defaults you have not read.
• Require TTLs on cache writes and enforce it in code review or a client wrapper.
• Alert on used_memory at 80 percent of maxmemory, and on mem_fragmentation_ratio above 1.5.
• Run the bigkeys scan on a schedule and track the top offenders over time.
• Separate cache data from durable data into different Redis instances so one policy fits each.
• Size hosts for the fork: if persistence is on, plan for RSS spikes toward twice used memory during BGSAVE and AOF rewrite.

When to call a senior engineer

Call for help when memory climbs even after evictions are enabled, when a bigkeys scan points at a data structure the team is afraid to touch in production, when fragmentation keeps returning after defrag, or when the instance needs to move to a larger node or a cluster without dropping writes. Erzon engineers can trace the growth to the exact keys and code paths, restructure the data, and resize or reshard the deployment while it stays online.