Home » How to Fix Redis OOM Command Not Allowed Error (Maxmemory Policy Setup)
Systems & Servers

How to Fix Redis OOM Command Not Allowed Error (Maxmemory Policy Setup)

✨ Quick Answer

The OOM command not allowed when used memory > 'maxmemory' error occurs when a Redis instance reaches its configured memory ceiling (maxmemory) while operating under the default noeviction policy. Under these conditions, Redis rejects all write operations (SET, HSET, LPUSH, SADD) with an Out-of-Memory exception to protect existing data from unmanaged deletion.

The OOM command not allowed when used memory > 'maxmemory' error occurs when a Redis instance reaches its configured memory ceiling (maxmemory) while operating under the default noeviction policy. Under these conditions, Redis rejects all write operations (SET, HSET, LPUSH, SADD) with an Out-of-Memory exception to protect existing data from unmanaged deletion.

Quick Diagnostics

Cause
Write commands fail with OOM command not allowed: Memory hit the maxmemory threshold while using the default noeviction policy
Solution
Configure an automatic eviction policy (allkeys-lru / volatile-lru) or increase maxmemory
Cause
The Redis daemon is killed by the Linux Kernel (OOM Killer): redis.conf lacks a explicit maxmemory boundary, exhausting host system RAM
Solution
Set an explicit maxmemory quota (e.g., 70-80% of total host physical memory)
Cause
High memory fragmentation ratio (mem_fragmentation_ratio > 1.5): The Jemalloc allocator holds unreleased pages after bulk key deletion operations
Solution
Enable Redis active defragmentation (activedefrag yes)

Step-by-Step Solution

  1. 1

    Step 1: Inspect Redis Memory Usage Statistics

    Connect to your Redis instance using redis-cli and query the memory subsytem status:

    BASH
    # Connect via redis-cli
    redis-cli -h 127.0.0.1 -p 6379
    
    # Query memory statistics
    127.0.0.1:6379> INFO memory
    
    # Key fields to examine:
    # used_memory_human:1.95G
    # maxmemory_human:2.00G
    # maxmemory_policy:noeviction
    
  2. 2

    Step 2: Change Eviction Policy (maxmemory-policy) Live

    To restore service immediately without restarting your Redis cluster or process, update the eviction policy at runtime:

    BASH
    # Enable Least Recently Used (LRU) eviction across all keys
    127.0.0.1:6379> CONFIG SET maxmemory-policy allkeys-lru
    
    # Optional: Dynamically increase maxmemory if free host memory is available
    127.0.0.1:6379> CONFIG SET maxmemory 3gb
    

    Key Redis eviction policies explained:

    • allkeys-lru: Evicts the least recently used keys out of all keys. Recommended for web caching layers.
    • volatile-lru: Evicts least recently used keys among those with an explicit TTL set.
    • allkeys-lfu: Evicts the least frequently used keys across the dataset.
    • noeviction: Rejects all write commands with an OOM error (default setting).
  3. 3

    Step 3: Persist Changes in Configuration File (redis.conf)

    To ensure settings persist across server reboots or container restarts, update your primary redis.conf:

    INI
    # Path: /etc/redis/redis.conf or custom redis.conf
    
    # Maximum RAM allocated to Redis (e.g., 2 Gigabytes)
    maxmemory 2048mb
    
    # Production eviction policy for cache workloads
    maxmemory-policy allkeys-lru
    
    # Enable background active defragmentation
    activedefrag yes
    

    Apply and verify the system service status:

    BASH
    sudo systemctl restart redis-server
    

Prevention Advice

Recommended security practices:

  • Enforce Key TTLs: Always specify Time-To-Live expiration intervals when writing cache entries from application code (SET key value EX 3600) to enable natural key garbage collection.
  • Scan for Big Keys: Routinely scan for bloated data structures using built-in analysis tools: redis-cli --bigkeys or redis-cli --memkeys.
  • Configure Memory Alerts: Set up monitoring alerts in Prometheus or Datadog to notify team members when used_memory exceeds 80% of configured maxmemory.
Author • Web Designer & App Creator

Rodolfo Castro

Web designer, app developer, and founder of SoporteCero. Specializing in UI/UX architecture, digital products, and modern web environments. Every tutorial and guide on SoporteCero is thoroughly tested and verified in our technical lab to ensure reliable, up-to-date solutions.