Resolving Redis 'OOM command not allowed' Errors

The Problem: Write Failures Due to Memory Exhaustion

When Redis returns the error (error) OOM command not allowed, it means the server has reached its defined memory limit and cannot allocate more space for new data. Unlike a system-level crash, this is a protective mechanism triggered by the maxmemory setting. The immediate result is that all write operations (SET, LPUSH, HSET, etc.) fail, while read operations continue to function.

Diagnostic Matrix: Identifying the Root Cause

Symptom	Likely Cause	Primary Metric to Check
Immediate OOM error on all writes	maxmemory-policy is set to noeviction	CONFIG GET maxmemory-policy
OOM error despite low used_memory	High memory fragmentation	mem_fragmentation_ratio
Slow performance followed by OOM	Memory leak or unexpected key growth	used_memory_peak
Redis process disappears (crash)	No maxmemory set; Linux OOM Killer intervened	dmesg | grep -i oom

Step-by-Step Investigation

Run these checks via redis-cli. Ensure you have the permissions to execute INFO and CONFIG commands.

1. Verify Memory Saturation:

   Run INFO memory and compare used_memory with maxmemory. If used_memory is equal to or greater than maxmemory, the limit has been hit.

2. Check the Eviction Policy:

   Run CONFIG GET maxmemory-policy. If the result is noeviction, Redis is configured to return an error rather than deleting old data to make room for new writes.

3. Analyze Fragmentation:

   In the INFO memory output, look at mem_fragmentation_ratio. A ratio significantly above 1.5 suggests that Redis is holding onto memory that the OS cannot reclaim, potentially triggering OOM limits prematurely.

Remediation Strategies

Scenario A: The Policy is 'noeviction'

If your application can tolerate the loss of less-recently-used data, change the policy to allkeys-lru. This allows Redis to evict keys to stay under the memory limit.

# Run on the Redis server via redis-cli
CONFIG SET maxmemory-policy allkeys-lru

Risk: This will permanently delete keys that have not been accessed recently. Ensure your data is either transient (cache) or backed up elsewhere.

Scenario B: Physical Memory is Available

If the host server has free RAM, increase the maxmemory limit to accommodate growth.

# Example: Increase limit to 4 Gigabytes
CONFIG SET maxmemory 4gb

Risk: Do not set maxmemory to the total physical RAM of the server. Leave room for the OS and Redis overhead to avoid triggering the Linux OOM Killer, which would crash the entire process.

Scenario C: High Fragmentation

If fragmentation is high and you are using the jemalloc allocator (default), you can attempt to defragment memory without restarting.

# Enable active defragmentation
CONFIG SET activedefrag yes

Risk: Active defragmentation consumes CPU cycles and may increase latency during peak traffic.

Verification and Rollback

To verify the fix, attempt a write operation that previously failed: SET test_key 1. Then, monitor INFO memory to ensure evicted_keys is increasing (if using an LRU policy) or that used_memory is now safely below the new maxmemory limit.

Rollback: To revert a policy change, run CONFIG SET maxmemory-policy noeviction. To revert a memory limit increase, set maxmemory back to its previous value. Note that decreasing maxmemory may trigger immediate mass eviction of keys.

Escalation Criteria

If the following conditions persist after the above fixes, escalate to a systems architect or database administrator:

• Memory usage continues to climb linearly despite allkeys-lru being active.
• The mem_fragmentation_ratio remains high despite activedefrag yes.
• The application requires 100% data persistence (cannot use eviction) and the available physical RAM on the host is fully exhausted.