A policy that may evict nothing
volatile-lru with no TTLs behaves exactly like noeviction
- machine-memory
- 16gb
- maxmemory-policy
- volatile-lru
Give the machine size and get a maxmemory value that leaves room for the things Redis needs outside that limit. The common failure is setting the limit to the machine size, which is reliably fatal during a background save.
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
volatile-lru with no TTLs behaves exactly like noeviction
The headroom matters more, not less, as the machine gets smaller
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
The fork during a background save needs memory proportional to the write rate, and it comes from outside the limit. The kernel kills the process during the save.
Instead:Use about 65 percent, and less if writes are heavy.
Nothing is eligible for eviction, so writes fail at the limit exactly as they would under noeviction.
Instead:Confirm keys get a TTL, or use the allkeys- variant.
Resident size is always larger, so the container is killed instead of the policy applying.
Instead:Set the container limit above maxmemory.
LRU and LFU are approximate: Redis samples that many keys and evicts the best of the sample. At 5 the choice is noticeably worse than true LRU.
Instead:Use 10 unless CPU is the bottleneck.
maxmemory bounds the dataset. It does not bound the process, and the difference is what kills instances.
A background save forks the process. Copy-on-write means the extra memory needed is proportional to what is WRITTEN during the save, not to the dataset, so a read-heavy instance barely notices and a write-heavy one can approach a second full copy. This is the most common cause of a Redis instance being OOM killed.
Replication buffers, client output buffers and the AOF rewrite buffer are all outside maxmemory. A single slow consumer of a large pub/sub stream can hold a substantial buffer, and it does not count towards the number you set.
Resident size is reliably larger than maxmemory for the reasons above. Setting both to the same number means the container is killed rather than the eviction policy being applied.
Every volatile- policy considers only keys with a TTL. If nothing in the keyspace has one, there is nothing eligible and the instance behaves exactly like noeviction: writes fail at the limit. This looks like the policy being ignored.
It caps the total memory used by client output buffers, which is one of the things that previously had no bound at all. On Redis 6 and earlier the only control is the per-class client-output-buffer-limit.