Diagnosing and Resolving Redis OOM Errors via Eviction Policies

The Symptom: OOM Errors and Write Failures

When a Redis instance reaches its configured memory limit, it may suddenly reject all write operations with an (error) OOM command not allowed when used memory > 'maxmemory' message. This occurs because the current eviction policy—the set of rules Redis uses to remove old data to make room for new data—is either disabled or cannot find eligible keys to delete.

Diagnostic Matrix: Identifying the Cause

Symptom	Likely Cause	Diagnostic Command
Immediate OOM error on all writes	noeviction policy is active	CONFIG GET maxmemory-policy
OOM error despite volatile-lru	No keys have a TTL (Time To Live) set	SCAN keys and check TTL
High memory usage but low used_memory	Memory fragmentation	INFO memory (check mem_fragmentation_ratio)
Random key disappearance	allkeys-lru or allkeys-random active	INFO stats (check evicted_keys)

Step-by-Step Resolution Path

Follow these checks in order to resolve memory pressure without causing unexpected data loss.

1. Verify Current Memory Limits and Policy

Run this command from the redis-cli on the host or a connected client with administrative permissions:

CONFIG GET maxmemory
CONFIG GET maxmemory-policy

If maxmemory is 0, Redis will use all available system memory, which may lead to the OS killing the process via the OOM Killer. If a limit is set and the policy is noeviction, Redis will refuse writes once the limit is hit.

2. Analyze Eviction Eligibility

If you are using a volatile policy (e.g., volatile-lru), Redis only evicts keys that have an expiration time set. If your application creates keys without a TTL, Redis cannot evict them, leading to OOM errors even if the policy is enabled.

Check if your keys have TTLs:

# Check TTL of a sample key (returns -1 if no TTL)
TTL your_key_name

3. Monitor Eviction Rates

Check if Redis is already attempting to evict keys but cannot keep up with the write volume:

redis-cli INFO stats | grep evicted_keys

A rapidly increasing evicted_keys count indicates that your memory limit is too low for your working set size, causing a "cache churn" where useful data is evicted too quickly.

Applying the Fix

Based on your findings, apply one of the following configuration changes. These commands should be run via redis-cli and require permissions to modify the configuration.

Scenario A: You need a strict cache (Lossy)

If Redis is used as a cache where data can be re-fetched from a database, use allkeys-lru. This evicts the least recently used keys regardless of whether they have a TTL.

CONFIG SET maxmemory-policy allkeys-lru

Scenario B: You have a mix of persistent and transient data

If some keys must never be deleted, ensure those keys have no TTL and set the policy to volatile-lru. This protects your persistent data while cleaning up expired or temporary entries.

CONFIG SET maxmemory-policy volatile-lru

Scenario C: You cannot lose any data

If noeviction is required, you must increase the physical memory or the maxmemory limit. If fragmentation is the issue (ratio > 1.5), enable active defragmentation (Redis 4.0+):

CONFIG SET activedefrag yes

Verification and Rollback

Verification: After changing the policy, perform a write operation that previously failed. Then, monitor INFO memory to ensure used_memory stabilizes near the maxmemory threshold without triggering OOM errors.

Rollback: To revert to the previous state, run CONFIG SET maxmemory-policy [previous_policy]. Note that changing the policy does not restore keys that were already evicted.

Limitations

• Sampling: Redis uses an approximation for LRU by sampling keys rather than maintaining a perfect linked list. This reduces CPU overhead but means the absolute least-recently-used key might not always be the one evicted.
• Cluster Distribution: In a Redis Cluster, memory limits are per-node. One node may hit OOM while others have plenty of space if your hash slots are unevenly distributed.