Redis OOM Command Not Allowed: Fix Memory Limits
Redis returns OOM command not allowed when used memory > 'maxmemory' when it has reached its configured memory limit and cannot free enough memory under its current eviction rules, so it rejects a command that would allocate more memory. The immediate fix depends on whether the Redis instance is a disposable cache, durable application data, a queue or stream, or a managed Redis Software deployment. Start by confirming the limit and eviction policy, then choose a repair that does not silently discard important data.
Use this table to match the error to the usual cause before changing any Redis setting.
| Symptom | Likely Cause | Safe Direction |
|---|---|---|
Writes fail and maxmemory-policy is noeviction |
Redis reached its limit and is configured not to remove keys | Reduce retained data or increase capacity; keep noeviction for important data |
Policy is volatile-lru, but writes still fail |
Few or no keys have TTLs, so Redis has no eligible keys to evict | Add expiration to cache keys, reduce stored data, or use an all-keys policy only for a pure cache |
Policy is allkeys-lru and evicted_keys rises steadily |
Eviction works, but the cache is too small for the active data set | Increase cache capacity or reduce the application’s cache footprint |
used_memory_rss is much higher than used_memory |
Memory fragmentation or allocator overhead is consuming host RAM | Investigate fragmentation and host memory separately from the Redis keyspace |
| Redis runs in a container or Kubernetes pod | Redis may be limited by both maxmemory and the container memory limit |
Leave host or pod headroom and make the Redis setting match the deployment’s memory budget |
What the Redis OOM Error Means
OOM means “out of memory.” It is not a Redis command, and it does not necessarily mean the operating system has run out of RAM.
The message means Redis cannot accept a memory-growing operation, such as SET, HSET, LPUSH, XADD, or a write performed by your application. Reads often continue to work, which can make Redis appear healthy while the application’s writes, sessions, queues, or cache updates fail.
Redis uses the maxmemory setting as its own memory ceiling. What it does at that ceiling depends on maxmemory-policy:
noevictionrejects memory-growing writes. This is the normal choice when Redis contains data you must not lose.allkeys-lrucan evict least-recently-used keys from the whole keyspace. Use it only when every key is safely rebuildable.volatile-lrucan evict only keys with an expiration time. It cannot help if the memory-heavy keys have no TTL.- Other volatile and all-keys policies use different selection methods, but the same data-safety decision applies.
Treat eviction as a cache policy, not an emergency repair for primary data.
A Redis limit also does not protect the host by itself. Redis needs memory beyond the logical data set for client buffers, replication, modules, persistence activity, and allocator overhead. A container can be killed by its runtime or Kubernetes even if Redis has a sensible maxmemory setting.
How to Fix the Redis OOM Error Safely
Step 1: Confirm the Limit, Policy, and Current Memory Use
Run these commands against the affected Redis instance before changing its behavior.
redis-cli INFO memoryredis-cli CONFIG GET maxmemoryredis-cli CONFIG GET maxmemory-policyLook for these fields in the memory output:
used_memory: Redis’s logical allocator use.used_memory_human: the readable form of that value.used_memory_rss: RAM mapped by the Redis process.maxmemory: the configured Redis limit.maxmemory_policy: the active eviction policy.
If maxmemory is 0, Redis has no internal maximum configured. In that case, check the container, pod, VM, or host limit instead; the process may be under pressure from the operating system rather than a Redis memory ceiling.
On Linux, inspect available host memory:
free -hFor a Docker container, inspect the container’s actual memory use and limit:
docker stats <container>For a Kubernetes deployment with Metrics Server available, inspect the pod:
kubectl top pod <pod> -n <namespace>I reproduce one problem at a time in a clean container because it removes machine-specific noise from Redis configuration and host-memory issues.
Step 2: Classify What Redis Is Storing
Choose the policy based on the data, not on the desire to make the error disappear.
| Redis Contents | Recommended Policy | What to Do First |
|---|---|---|
| Pure cache backed by a database or API | allkeys-lru can be appropriate |
Verify every key can be recreated |
| Cache keys that all have TTLs | volatile-lru can be appropriate |
Confirm large cache keys actually expire |
| Sessions, locks, rate-limit state, queues, streams, or job data | Usually noeviction |
Reduce retention, drain consumers, or add capacity |
| Mixed cache and important data | Separate workloads into different Redis instances or databases where possible | Do not enable all-keys eviction for the shared instance |
| Persistent Redis Software database | Follow the database’s memory and replication plan | Account for replication, modules, shards, and node headroom |
For a pure cache, eviction is an expected part of operation. For streams and queues, eviction can discard messages that consumers have not processed. For session data, eviction can log users out or break application workflows.
Step 3: Apply the Correct Recovery Path
For a Rebuildable Cache
If every key is disposable and can be recreated, enable all-keys LRU eviction. This allows Redis to evict older cache entries instead of rejecting new writes.
redis-cli CONFIG SET maxmemory-policy allkeys-lruIf the current memory limit is too low for the intended cache size and the host has real spare capacity, set a larger limit that still leaves RAM for the operating system, Redis overhead, and other services.
redis-cli CONFIG SET maxmemory <memory-limit>Replace <memory-limit> with the limit your host or container can safely support, such as a Redis-compatible memory value. Do not set it equal to all physical RAM or the complete Kubernetes pod limit.
For Important Data, Streams, Queues, or Sessions
Keep noeviction and stop the data from growing without bound. Common causes include:
- Cache entries written without expiration.
- Lists pushed faster than consumers remove items.
- Streams retained indefinitely.
- Jobs or events retried repeatedly.
- Large values duplicated under changing keys.
- A producer that is running faster than its consumers.
Find unusually large keys without using the blocking KEYS * command:
redis-cli --bigkeysScan a known application prefix:
redis-cli --scan --pattern 'your-prefix:*'Inspect the size of a specific candidate key:
redis-cli MEMORY USAGE your:key:nameInspect a stream that may be retaining events:
redis-cli XINFO STREAM your:stream:keyAdd TTLs through the application for cacheable values. For data that is known to be obsolete and safely disposable, remove only the specific identified key:
redis-cli UNLINK your:key:nameDo not use FLUSHALL as a routine response to this error. It removes the entire dataset and can destroy sessions, queues, durable state, and application coordination data.
Step 4: Test Writes and Make the Fix Persistent
After freeing space, changing capacity, or enabling an appropriate cache policy, test that Redis can accept a small expiring write:
redis-cli SET oom-check 1 EX 60Then remove the test key:
redis-cli DEL oom-checkA CONFIG SET change is live but may not survive a restart. Make the configuration persistent by updating the Redis configuration source used by the deployment:
redis-cli CONFIG REWRITEFor Docker, Kubernetes, Helm, managed Redis, or immutable infrastructure, update the Redis configuration source used by the deployment instead. For example, change the mounted redis.conf, chart values, operator custom resource, or managed-service setting, then redeploy or restart in the normal way. Do not rely on an interactive change that disappears after the next pod replacement.
Investigate Why Redis Memory Keeps Growing
Fixing the immediate OOM condition is only temporary if the keyspace keeps growing.
Start with the application behavior. A cache should normally have expirations or bounded key churn. A queue should have consumers keeping up with producers. A stream should have a deliberate retention or trimming design. Repeatedly writing the same logical event under new IDs can produce unbounded memory use even when traffic looks modest.
Check eviction activity after choosing a cache policy:
redis-cli INFO statsThe evicted_keys counter should remain zero on a Redis instance intended to hold durable state. A rising counter is normal only for a cache designed to evict entries.
Also inspect client pressure:
redis-cli INFO clientsSlow clients can accumulate output buffers, which consume memory outside the data you expected to store. If used_memory_rss stays far above used_memory, investigate memory fragmentation or allocator behavior rather than assuming that the data set itself is too large.
For Kubernetes, compare Redis metrics with the pod memory limit, restart count, and termination reason. A Redis OOM reply is an application-level refusal; a pod marked OOMKilled is a container-level failure. You can experience either one, or both, when the memory budget is poorly aligned.
Redis Software and Active-Active Memory Limits
Redis Software and Active-Active deployments need additional capacity planning because memory is used for more than the primary data set.
Size Active-Active Databases for Replication
Active-Active replication can require up to two times the original data size per instance. The synchronization backlog is also allocated by default at 1% of the database size. Modules, throughput-driven shard counts, regular replication, and Active-Active metadata add further overhead.
An Active-Active eviction policy starts evicting keys when an instance reaches 80% of its memory limit. That behavior is part of the database design, not a substitute for calculating enough capacity for replicated data and overhead.
The Active-Active database planning guidance details the replication, synchronization, module, shard, and node-memory considerations that determine capacity.
Configure Replication OOM Headroom
Redis Software Active-Active databases running Redis version 8.4 or later support replication_oom_threshold_percent. This reserves memory below maxmemory for internal replication and garbage-collection work.
The default is 5% of maxmemory. With the default setting, 5% of maxmemory is reserved for internal replication and garbage-collection work, so external writes can be rejected before the full maxmemory limit is reached. If memory reaches the full maxmemory limit anyway, normal OOM behavior applies to all operations.
Set replication_oom_threshold_percent as an integer from 0 to 20 across all participating clusters. The configuration endpoint is:
PATCH https://<host>:<port>/v1/crdbs/<crdb_guid>The relevant request body section is:
{
"default_db_config": {
"replication_oom_threshold_percent": "<integer from 0 to 20>"
}
}Redis Software version 8.0.16 and later supports both global and local Active-Active configuration changes in the Cluster Manager UI. Use a global configuration change when the setting must remain consistent across participating clusters.
Account for High-Velocity Ingestion
During rare periods of high-velocity ingestion, Redis Software can temporarily use up to 200% of the configured database memory limit. This adaptive allocation can prevent valid transactions from being rejected during rapid ingestion, but the underlying nodes still need sufficient RAM to absorb the temporary demand.
Monitor node memory, not just the database’s configured limit, during bulk imports, connector catch-up periods, or sudden producer bursts. The database memory-limit documentation explains why temporary high-velocity ingestion can require node memory beyond the configured database limit and describes related low-RAM protections.
Confirm the Fix and Prevent a Repeat
After deployment, confirm all of the following:
- The application can write to Redis without OOM replies.
- The active
maxmemory-policymatches the importance of the stored data. - Redis has an intentional retention plan for caches, lists, streams, and queues.
evicted_keysrises only on instances designed as caches.- The host, container, or pod has memory headroom beyond Redis’s data limit.
- Runtime changes are represented in deployment configuration and survive a restart.
- Alerts exist for sustained growth toward
maxmemory, Redis OOM errors, eviction activity, and container or host memory pressure.
The next useful action is to identify the largest key family or fastest-growing stream, then fix the application retention rule that created it. That turns an OOM response from a recurring outage into a capacity signal.
Frequently Asked Questions
What Is the OOM Command in Redis?
There is no Redis command named OOM. OOM is the error response Redis returns when it cannot allocate memory for an operation, commonly because used_memory has reached maxmemory and the configured policy cannot evict an eligible key.
What Is the Default Redis Maxmemory Policy?
The default Redis maxmemory-policy is noeviction. With that policy, Redis rejects commands that need additional memory after it reaches maxmemory, rather than deleting existing keys.
Is It Safe to Switch to Allkeys-LRU?
Switching to allkeys-lru is safe only when every key in that Redis instance is disposable and can be rebuilt from another source. allkeys-lru may evict any key, including keys that an application treats as sessions, locks, queues, or state, so it is not a safe emergency fix for a mixed or durable Redis workload.
Why Does Moodle Show a Redis Maxmemory OOM Error?
Moodle is receiving a Redis write failure; the underlying problem is Redis capacity or eviction policy, not a Moodle-specific memory limit. Check whether Redis is being used for disposable caches, sessions, locks, or other application state before enabling eviction, because evicting session or lock data can disrupt users and background jobs.
Can I Raise Maxmemory Without Restarting Redis?
Yes, Redis can apply a live change with CONFIG SET maxmemory <memory-limit>. The new value must still leave room for the operating system, container runtime, replication, persistence overhead, modules, and other services; persist the change with CONFIG REWRITE when that command is supported, or update the deployment configuration.
Why Can Active-Active Redis Reject Writes Before Maxmemory?
On Redis Software Active-Active databases running version 8.4 or later, the default replication_oom_threshold_percent reserves 5% of maxmemory for internal replication and cleanup work. External writes can be blocked at that threshold so replicas have a chance to recover rather than falling behind or becoming desynchronized.