Redis / Advanced: persistence, distribution and operations / Lesson 16

Memory, eviction and capacity

Distinguish TTL expiry, policy eviction and memory errors. Budget data, overhead, buffers and persistence peaks from evidence rather than universal maxmemory values.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain maxmemory policy choices and cache/authority consequences.
Interpret process memory and observed growth with the correct scope.

Eviction is a data-loss policy for memory pressure

When configured memory limits are reached, Redis applies its selected maxmemory policy to eligible keys or rejects qualifying writes under noeviction. Policy choice must follow data purpose: removing a reconstructible cache entry differs from removing pending authoritative work or session security state. LRU and LFU families are approximate policies rather than a perfect global ordering oracle. Volatile policies consider keys with an expiry and may have no eligible candidates when all keys are persistent. Expiration remains a separate deadline mechanism, so an evicted key can disappear well before its TTL would have ended.

Read memory and keyspace signals in context

The inspection commands below are non-runnable examples for an already authorized training connection. INFO memory and INFO stats provide different categories of evidence, including version-dependent memory and eviction/expiration counters. No healthy numbers or thresholds are fabricated. Counters can reset and one sample does not identify which application key disappeared. Correlate key identity, writer behavior, TTL and memory policy before attributing a miss. Managed services may provide equivalent metrics while limiting direct commands; use that supported interface rather than escalating privileges just to copy a tutorial.

redis Non-runnable memory and lifecycle inspection

INFO memory
INFO stats

Actual fields and values depend on the server and privileges. Distinguish expired_keys from evicted_keys and inspect memory scope rather than inferring a universal limit.

maxmemory is not a complete process-RAM ceiling

Redis memory accounting, allocator behavior, fragmentation, client buffers, replication/persistence buffers and copy-on-write can make resident memory differ from the logical dataset and eviction accounting. Some memory is reported separately from the amount used for eviction decisions. Leave evidence-based headroom for the actual topology and workload rather than setting maxmemory equal to all host RAM. A large or expensive key can also create latency and network pressure even when total dataset memory is acceptable. Key count alone is therefore not a reliable capacity measure. Investigate bytes, types, values and traffic together without dumping sensitive production data.

Expose capacity assumptions with an offline budget

This arithmetic adds invented dataset, buffer and persistence-peak allowances, then compares them with a fictional capacity. It demonstrates that the dataset can fit while the complete modeled demand does not. The numbers are not Redis tuning recommendations or measurements of allocator behavior. A real budget needs workload observations, deployment constraints and failure peaks, including replication synchronization and restore/rebuild. Treat missing components as uncertainty rather than subtracting them to obtain a comfortable answer. The model changes no process memory or configuration and does not run a load test.

python Offline hypothetical capacity budget

capacity_mib = 100
budget = {'dataset': 70, 'buffers': 15, 'persistence_peak': 25}
assert budget['dataset'] < capacity_mib
assert sum(budget.values()) == 110
assert sum(budget.values()) > capacity_mib

The model needs 110 MiB against 100 MiB capacity. These labels are invented accounting buckets, not exact Redis metrics or a sizing formula.

Fix the evidenced growth and authority problem

Choose a remedy after distinguishing legitimate growth, a hot/large key, unbounded queues, missing TTL, excess replication buffers or a policy mismatch. Reducing retention, partitioning application keys, adjusting admission or adding capacity can have different correctness and operational costs. Do not casually enable eviction for a dataset that must not lose arbitrary keys, or disable persistence merely to hide a memory peak. Track hit/miss and source pressure after changes. Acceptance should include latency, write rejection, evictions, recovery and business invariants under representative conditions, not only a lower memory graph.

Common errors and fixes

OOM command not allowed when used memory > 'maxmemory'.

Why it happens: The policy and memory state prevent the attempted write.
How to fix it: Inspect memory accounting, eligible eviction keys and workload growth under the service plan.
Prevent it next time: Budget headroom and monitor write rejections before saturation.

Keys disappear before their TTL

Why it happens: Memory eviction or another writer was mistaken for expiry.
How to fix it: Correlate eviction counters, policy and key-specific write evidence.
Prevent it next time: Separate expiry and eviction in monitoring and key contracts.

Process RAM exceeds the assumed maxmemory ceiling

Why it happens: Dataset eviction accounting was treated as total resident memory.
How to fix it: Review buffers, allocator/copy-on-write and deployment overhead.
Prevent it next time: Size using measured peak demand rather than key count alone.

Check your understanding

1. All keys lack TTL but the policy only evicts volatile keys. What risk should be investigated?

Show worked solution

There may be no eligible eviction candidates, so qualifying writes can fail under memory pressure. Confirm the exact policy and key lifecycle rather than assuming every eviction policy can remove any key. Choose a deliberate remedy based on whether the data is disposable, then test write outcomes and source fallback behavior.

2. A memory graph falls after arbitrary eviction. Does that establish a successful capacity fix?