Redis evicts keys when memory usage reaches its configured memory limit, and the eviction policy determines which keys go. The default is noeviction, which does not evict at all — it starts rejecting writes with an OOM error. For a cache you almost always want allkeys-lru. For a datastore holding data you cannot lose, noeviction is correct and you size for the workload instead.
What Triggers a Redis Eviction Policy to Run?
Two things have to be true, and the first is a memory limit. Redis is an in-memory data store, so the maxmemory directive sets the ceiling. When usage reaches it, the policy runs, redis decides what to evict, and it will evict keys to free space for new data.
CONFIG GET maxmemory-policyIf the memory limit is 0 in production, that is the first thing to fix.
The Eight Available Redis Eviction Policies
| Policy | Scope | How it picks |
|---|---|---|
noeviction | — | Evicts nothing; write commands fail with an OOM error |
allkeys-lru | All keys | Least recently used |
allkeys-lfu | All keys | Least frequently used |
allkeys-random | All keys | Random |
volatile-lru | Keys with a TTL | Least recently used |
volatile-lfu | Keys with a TTL | Least frequently used |
volatile-random | Keys with a TTL | Random |
volatile-ttl | Keys with a TTL | Shortest remaining time to live |
Redis provides eight redis key eviction policies. The default behavior is noeviction, which surprises anyone assuming a cache evicts automatically — it does not until told to. allkeys-lru is the right default for a cache. These available eviction policies split into two families.
Volatile vs Allkeys Redis Eviction Policy Options
The volatile-* policies only consider keys that have a TTL set. That sounds safer — evict only the disposable things — and it has a trap.
If no keys have an expiration set, a volatile policy has nothing to evict and behaves exactly like noeviction. Memory fills, writes start failing, and the policy you configured looks like it did nothing. It did precisely what it was told.
This applies to the primary database the same way. Use a volatile option only when deliberately mixing cached data (with TTL) and persistent data (without) in one redis instance, and only when the cached portion is large enough to reclaim from. Otherwise use an allkeys policy, or split the workloads — in a Redis cluster that also keeps eviction strategies independent per shard.
How the LRU algorithm and LFU actually work
Neither is exact, and understanding why matters when tuning.
Recency-based selection is approximate. The LRU algorithm would otherwise track access order across the whole keyspace, which costs time. Instead it samples candidate keys and drops the least recently used among them — the number of samples to check is configurable:
maxmemory-samples 5Five is the default. Raising it improves accuracy at some CPU cost; lowering it to 3 is faster and noticeably worse. Sampling is why a hot key is occasionally dropped — it was not among the good candidates for eviction that round.
The frequency option tracks how often a key is used rather than when. It uses a probabilistic counter that decays over time, so keys used often keep a higher chance of remaining. Two tunables:
lfu-log-factor 10 # how fast the counter saturates for frequently accessed keys
lfu-decay-time 1 # minutes before an unused counter decaysThis is the better cache policy when access patterns are skewed — a few very hot keys among many cold ones. It stops a burst of one-off reads pushing out popular data, which recency-based selection will do. With a long tail used rarely, it gives better cache performance.
How to Configure a Redis Eviction Policy
At runtime, no restart needed:
CONFIG SET maxmemory 4gb
CONFIG SET maxmemory-policy allkeys-lruPersist it in redis.conf so it survives a restart:
maxmemory 4gb
maxmemory-policy allkeys-lru
maxmemory-samples 5How to Monitor Redis Eviction Policy Behaviour
INFO memory # used_memory, maxmemory, maxmemory_policy
INFO stats # evicted_keys, expired_keys, keyspace_hits, keyspace_missesWatch three things on every eviction cycle:
evicted_keysrising steadily — undersized for the working set, or the wrong policy- Hit rate falling while eviction rates climb — recently used keys are being dropped just before they are needed
used_memorysitting at the memory limit — normal for a cache, alarming for a datastore
The sizing mistake that crashes production
This is the part the documentation does not emphasise, and we see it repeatedly.
A configured ceiling does not account for what Redis needs during a background save. When Redis forks to write a snapshot, the child process shares memory with the parent via copy-on-write. Every key modified during the save causes a page copy — so under write load, total process memory climbs toward double the dataset.
We investigated a customer seeing repeated crashes at roughly 60 percent memory utilisation. Nothing in the Redis metrics explained it: usage sat well under the limit and no alert threshold had been crossed. The cause was fork behaviour during backups, and the fix was kernel-level overcommit tuning rather than any Redis setting.
The practical rules that follow:
- Size it to roughly 50–60% of available RAM on an instance that persists under write load. Not 80%, and certainly not 100%.
- Alert on total process memory, not just
used_memory. The metric that kills you is not the one Redis reports. - If you do not need snapshots on that instance, turn them off — the problem disappears entirely.
A Redis eviction policy is irrelevant if the process dies before eviction ever triggers.
Seeing Redis crashes that memory metrics do not explain? These usually sit below Redis — in
kernel memory behaviour or persistence configuration. AceMQ runs structured Redis assessments that
find them. Talk to an AceMQ engineer.
Best practices for memory management
Always set a limit. Use the recency option for caches and noeviction for datastores. Never pick a volatile option unless keys genuinely carry TTLs. Leave headroom for fork overhead, and persist config to the file rather than only via CONFIG SET.
Any application using Redis as a cache should have its Redis eviction policy set deliberately rather than inherited. For the availability side of the same system, see Redis high availability, or Redis consulting and support for help with a production estate.
FAQ
What is the default Redis eviction policy?
noeviction. Redis does not evict anything by default — once maxmemory is reached, write commands fail with an out-of-memory error while reads continue working.
Which Redis eviction policy should I use?
allkeys-lru for most caches. allkeys-lfu when a small set of keys is far hotter than the rest. noeviction when the data is not disposable and losing a key would be data loss.
What is the difference between LRU and LFU in Redis?
One evicts by recency of access, the other by frequency of access using a decaying counter. The frequency option resists a burst of one-off reads pushing out popular keys, which makes it better for skewed access patterns.
Why is my volatile eviction policy not evicting anything?
Because no keys have a TTL. Volatile policies only consider keys with an expiration set — with none, they behave identically to noeviction.
Is recency-based eviction exact?
No. It samples a configurable number of candidate keys — five by default via maxmemory-samples — and evicts the least recently used among them. Raising the sample size improves accuracy at some CPU cost.
What should I size it to?
For an instance that takes snapshots under write load, roughly 50–60% of available RAM, leaving room for copy-on-write overhead during a fork. Sizing to nearly all available RAM is how instances die at what looks like moderate utilisation.
