Fix Redis OOM command not allowed error

Learn why Redis throws OOM command not allowed when used memory greater than maxmemory, how to diagnose it with redis-cli and free -m, and how to fix it by setting a sane maxmemory and eviction policy.

Prerequisites

A server running Redis with sudo access
Basic familiarity with redis-cli
Ability to edit configuration files and restart services

What this solves

When Redis hits its configured memory limit, write commands start failing with OOM command not allowed when used memory > 'maxmemory'. This happens because the default maxmemory-policy is noeviction, which rejects writes instead of evicting old keys once the limit is reached.

This tutorial shows you how to confirm the cause, size maxmemory correctly for your server, choose the right eviction policy, and apply the fix safely without losing data you need.

Step-by-step configuration

Understand what the error means

Redis enforces a memory ceiling defined by maxmemory. If that value is set but the eviction policy is noeviction (the default), Redis will refuse any command that would use more memory once the limit is hit. Read-only commands still work, but writes, including SET, LPUSH, and even some background operations, fail outright.

This is not a crash. It is Redis protecting itself from running out of memory and being killed by the kernel OOM killer. The fix is to either give Redis more headroom, let it evict old data automatically, or both.

Check current Redis memory usage

Connect with redis-cli and inspect the memory section of INFO. This tells you exactly how much memory Redis thinks it is using versus what it is allowed to use.

redis-cli INFO memory

Look specifically at these fields in the output:

redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy'

If used_memory_human is at or above maxmemory_human and maxmemory_policy shows noeviction, you have found the root cause.

Check system memory with free -m

Before raising maxmemory, confirm the host actually has spare RAM. Redis memory limits should never exceed what the system can safely allocate alongside the OS, other services, and swap.

free -m

A typical output looks like this:

              total        used        free      shared  buff/cache   available
Mem:           7935        4210         412         120        3313        3400
Swap:          2047           0        2047

A safe rule of thumb is to set maxmemory to no more than 50-70% of total physical RAM on a dedicated Redis host, leaving room for the OS, fork-based persistence (RDB/AOF rewrites), and other processes. If Redis shares the box with other services, size it even more conservatively. For a deeper look at what else is consuming RAM, see find out which process is using all your CPU or memory on Linux.

Decide on maxmemory and a maxmemory-policy

There are two parts to the fix: how much memory Redis is allowed to use, and what it does when it hits that limit.

maxmemory sets the hard ceiling, for example maxmemory 2gb. Pick a value based on the free -m output from the previous step, not an arbitrary round number.

maxmemory-policy controls behavior at the limit. The two most common choices:

Policy	Behavior	Use when
noeviction	Rejects writes once maxmemory is hit, returns OOM errors	Redis is your primary datastore and losing any key is unacceptable
allkeys-lru	Evicts least recently used keys across the whole keyspace to make room	Redis is used as a cache or session store where stale data can be dropped
volatile-lru	Evicts least recently used keys, but only among keys with a TTL set	You mix cacheable data (with TTL) and persistent data (without TTL) in the same instance
allkeys-lfu	Evicts least frequently used keys across the whole keyspace	Access patterns are skewed and you want to keep hot keys over recently touched ones

For most caching and session-storage use cases, allkeys-lru is the safest default. If Redis is backing something like job queues or financial counters where losing a key is a real problem, keep noeviction but fix the underlying memory sizing instead, and consider application-level backpressure.

Warning: Switching to an eviction policy means Redis will silently delete keys to stay under maxmemory. Never set allkeys-lru or similar on an instance that holds data without a backing source of truth, you will lose it permanently.

Edit redis.conf

Locate your Redis configuration file. On Ubuntu and Debian it is typically at /etc/redis/redis.conf. On AlmaLinux and Rocky it is usually at /etc/redis.conf or /etc/redis/redis.conf depending on the install method.

sudo find /etc -iname 'redis.conf' 2>/dev/null

Open the file and set or update these two directives:

maxmemory 2gb
maxmemory-policy allkeys-lru

If the lines already exist but are commented out with a leading #, uncomment them instead of adding duplicates. You can confirm with grep before and after editing.

grep -E '^(maxmemory|maxmemory-policy)' /etc/redis/redis.conf

Apply the change without editing the config file (optional, immediate)

You can apply new memory settings live with CONFIG SET to fix the problem instantly, then persist them to redis.conf afterward so they survive a restart.

redis-cli CONFIG SET maxmemory 2gb
redis-cli CONFIG SET maxmemory-policy allkeys-lru

Note: CONFIG SET changes are in-memory only. If you do not also update redis.conf, the next restart will revert to the old values.

Restart the Redis service safely

After editing redis.conf, restart the service so the file-based configuration takes effect and matches what CONFIG SET applied live.

sudo systemctl restart redis-server
sudo systemctl status redis-server

sudo systemctl restart redis
sudo systemctl status redis

Before restarting in production, check if the Redis instance has persistence enabled (RDB or AOF). If so, a restart triggers a reload from disk, which is safe but can briefly spike memory and CPU on large datasets. Schedule restarts during low-traffic windows where possible.

Verify your setup

Confirm the new limits are active and that Redis is no longer rejecting writes.

redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy

Test that writes succeed under load by checking memory stats again after some traffic.

redis-cli INFO memory | grep -E 'used_memory_human|maxmemory_human|evicted_keys'

A nonzero and growing evicted_keys count with allkeys-lru is expected and healthy, it means Redis is reclaiming space instead of rejecting writes. If you kept noeviction, watch used_memory_human over time and alert before it approaches maxmemory_human.

Common issues

Symptom	Cause	Fix
OOM error persists after setting maxmemory	Config edited but service not restarted, or CONFIG SET not applied	Run `redis-cli CONFIG GET maxmemory` to confirm the live value matches redis.conf
Redis restart takes a long time	Large RDB or AOF file being loaded into memory on startup	Check `rdb_last_save_time` and AOF size, consider BGREWRITEAOF during low traffic before restarting
Keys disappear unexpectedly after enabling eviction	allkeys-lru or allkeys-lfu evicting keys you expected to persist	Switch to volatile-lru and ensure important keys are set without a TTL
System runs out of memory even with maxmemory set	maxmemory set too close to total RAM, leaving no room for fork-based persistence	Lower maxmemory to 50-70% of total RAM, verify with `free -m`
Writes fail even though used_memory is below maxmemory	Memory fragmentation or lazy-free in progress	Check `mem_fragmentation_ratio` in INFO memory, consider `activedefrag yes`

Next steps

Running this in production?

Want this handled for you? This works for a single server. When you run multiple environments or need this available 24/7, keeping memory limits tuned, eviction policies correct and Redis patched across every instance is a different job. See how we run infrastructure like this for European teams.

#redis #oom #memory management #maxmemory #redis-cli #troubleshooting #linux

Fix Redis OOM command not allowed when used memory greater than maxmemory