## TL;DR
Check the eviction policy first (if it is noeviction, Redis rejects writes instead of evicting anything), then find the biggest keys with MEMORY USAGE sampling and evict the large, low-value ones first. The durable fix is TTLs on everything cache-like and an eviction policy that matches the workload, not just raising maxmemory.

## The error

```text
OOM command not allowed when used memory > maxmemory
```

## Steps

1. Check memory pressure and the eviction policy:

```
INFO memory
CONFIG GET maxmemory-policy
```

   Expected: `used_memory` at or above `maxmemory`, and a policy like `noeviction` (which rejects writes) or a volatile/allkeys variant.

2. If the policy is `noeviction`, decide the intended behavior: for a cache, switch to an evicting policy (e.g. allkeys-lru); for a primary store where losing keys is unacceptable, keep noeviction and free space deliberately instead.

   Expected: a conscious choice recorded; no more surprise write rejections for cache workloads.

3. Find the biggest keys. Scan and sample memory per key (do this on a replica or during low traffic on large instances):

```
redis-cli --bigkeys
```

   Expected: a short list of the largest keys by type, e.g. one 400MB hash or a few giant lists.

4. Inspect the top candidates individually before deleting:

```
MEMORY USAGE [key]
TTL [key]
```

   Expected: confirmation of size, and whether the key has a TTL (no TTL on cache data is a bug).

5. Evict in this order: (1) giant keys that are recomputable cache with no TTL, (2) expired-but-lingering data, (3) low-value cold keys under an LRU policy. Then set TTLs on everything cache-like so the problem cannot rebuild silently.

   Expected: used_memory drops below maxmemory; writes succeed; TTLs prevent regrowth.

## Use this when

- Redis clients get OOM errors on write commands while used memory sits at the maxmemory cap.
- used_memory is pinned at maxmemory and you need to choose what goes.
- You are deciding between evicting data and raising the cap.

## Not for this skill when

- The error is an OS-level OOM killer event (that is host memory, not the Redis maxmemory cap).
- A single write is huge (a multi-GB value will fail no matter what you evict; chunk the value).
- Redis is used as a primary store with persistence and every key is precious (then the answer is capacity planning, not eviction).

## Variant phrasings

### redis oom command not allowed used memory maxmemory
The canonical error; steps above.

### redis rejecting writes at memory limit
Check maxmemory-policy first; noeviction rejects, LRU evicts.

### which redis keys are using the most memory
redis-cli --bigkeys plus MEMORY USAGE sampling.

## Why it happens
Redis enforces maxmemory as a hard cap. With an evicting policy it makes room automatically; with `noeviction` (the default) it refuses writes once the cap is hit, which surfaces as this OOM error on the client. Memory fills because cache keys lack TTLs, one key grows without bound (an ever-growing list or hash), or the dataset simply outgrew the cap.

## Edge cases

- `--bigkeys` scans the whole keyspace and can be slow on huge instances; sample with it on a replica, or use it during off-peak.
- Deleting one giant key is instant for the client but Redis reclaims the memory asynchronously; watch used_memory, not just the DEL return.
- MEMORY USAGE reports one key; extrapolate carefully - a thousand 1MB keys outrank one 400MB key in aggregate.
- Raising maxmemory past physical RAM just moves the failure to the OS OOM killer, which is worse; keep maxmemory below RAM minus headroom for replication buffers and the OS.

## Provenance

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