redis OOM command not allowed when used memory > maxmemory

TL;DR

Redis refuses writes because it hit maxmemory, almost always from keys written without TTLs or an eviction policy of noeviction. Set an eviction policy that matches your cache semantics (usually allkeys-lru), add TTLs to cache keys, and find the biggest keys to trim.

redis OOM command not allowed when used memory > maxmemory

Use this when

• Redis writes fail with the OOM error
• Memory climbs monotonically until writes stop
• An agent caches aggressively with no expiry

Not for this skill when

• Clients cant connect (thats network or auth)
• Commands are slow (thats big keys or blocking ops)
• Replicas lag (thats replication)

Steps

1. Confirm memory pressure and the current policy:

redis-cli INFO memory | grep -E "used_memory_human|maxmemory_human"
redis-cli CONFIG GET maxmemory-policy

Expected output: used_memory near maxmemory, and the policy (often noeviction, which refuses writes instead of evicting).

1. Set an eviction policy that fits a cache:

redis-cli CONFIG SET maxmemory-policy allkeys-lru

Expected output: OK. With allkeys-lru, Redis evicts the least-recently-used keys to make room instead of failing writes. Persist it in redis.conf so a restart doesnt revert it.

1. Find the biggest keys and check for missing TTLs:

redis-cli --bigkeys
redis-cli INFO keyspace

Expected output: the largest keys by type. If --bigkeys shows giant hashes or sets with no TTL, those are your leak.

1. Add TTLs where the agent forgot them:

# set with expiry instead of bare set
r.setex(cache_key, 3600, value)

Expected output: keys expire after an hour and memory stabilizes. Audit every set call in the caching layer for a TTL.

Variant phrasings

OOM on a queue (list) workload

Lists used as queues with noeviction fill up and then refuse pushes. Either consume faster, cap the list length, or switch the policy.

memory keeps growing after setting a policy

The policy only evicts when maxmemory is hit and only for eligible keys. Keys with no eviction candidacy (volatile-* policies plus persistent keys) still accumulate.

Why it happens

Redis is an in-memory store with a configured ceiling. noeviction (the default) protects existing data by refusing new writes, which is correct for a primary store but wrong for a cache. Agent caching code typically calls set without expiry, so every cached value lives forever and the ceiling arrives as a surprise.

Edge cases

• allkeys-lru evicts any key, including ones your app treats as permanent; use volatile-lru plus TTLs if some keys must never be evicted.
• Eviction is approximate LRU; with maxmemory-samples at default 5, the "least used" choice is sampled, not exact.
• On Redis Cluster, maxmemory is per node; one hot node can OOM while the cluster looks healthy overall.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7OYPFeSKdmbNpO12zktZVA