Redis Evictions in Production: Diagnose Policy, Memory, and Hot Keys

An eviction counter means Redis removed keys to stay within its configured memory limit. The correct response depends on whether Redis is a disposable cache, a mixed workload, or a primary data store. Adding memory may delay the next incident while leaving oversized keys, missing TTLs, or a mismatched policy untouched.

The practical problem

A cache uses allkeys-lru, yet hit rate drops during a nightly import. Metrics show used_memory below the host limit but near maxmemory, large JSON values entering without TTLs, and allocator fragmentation after the burst. The team caps object size, adds TTLs, pipelines smaller records, isolates the import cache, and load-tests the eviction curve. It does not raise maxmemory above the container limit, which would invite an OOM kill.

This scenario defines the boundary for redis eviction troubleshooting: the system of record, the component that enforces the decision, the asset or money at risk, and the condition that ends an exception. If one of those is unknown, discover it before changing production or presenting the number.

A step-by-step workflow

1. Scope the system. Confirm persistence and data-loss expectations.
2. Establish the baseline. Inspect maxmemory and policy.
3. Apply the control. Compare logical memory, RSS, allocator fragmentation, container limit, and host pressure.
4. Test failure paths. Graph evictions beside commands, misses, latency, expirations, and reconnects.
5. Verify the result. Sample key types, sizes, TTLs, and namespaces safely.
6. Record ownership. Identify burst writers and hot readers.
7. Close the loop. Reproduce with representative value distributions.
8. Review the change. Choose policy and capacity from workload behavior..

Prove the failure paths

Start with a healthy case based on “Confirm persistence and data-loss expectations”, then repeat the exercise while deliberately violating the assumption behind “graph evictions beside commands, misses, latency, expirations, and reconnects”. Capture the observable result, the alert that should fire, and the person who decides whether to stop or continue. Next, simulate the most credible failure in this guide: noeviction can turn memory pressure into write failures. The test passes only when the team detects the condition, limits its impact, and restores service or the decision model without relying on undocumented knowledge. A final replay should cover KEYS * can block a busy server; this is the check most likely to reveal that a control works in a diagram but not at the actual boundary.

Evidence worth keeping

• Retain configuration snapshots
• Memory metrics
• Key-size samples
• TTL histograms
• Command rates
• Deployment events
• And application errors. Define a budget for evictions or write failures according to the role of the instance.

Attach each record to the concrete object under review: the relevant asset, release, customer, contract, key, query, or configuration. Preserve timestamps and version identifiers so another reviewer can reconstruct the sequence. The evidence list above should answer three questions: what was true before the change, what changed, and what proves the intended outcome. For this topic, the most useful cross-check is “sample key types, sizes, TTLs, and namespaces safely”. Keep sensitive fields out of screenshots and tickets; retain structured exports or signed records when they provide stronger provenance. Set retention according to incident, audit, privacy, and contractual needs rather than keeping everything indefinitely.

Common mistakes

• noeviction can turn memory pressure into write failures.
• volatile policies fail expectations when many keys lack TTLs.
• KEYS * can block a busy server.
• average object size hides a heavy tail.
• increasing container memory without changing Redis maxmemory wastes capacity.
• using eviction as expiration creates unpredictable retention..

A focused operating checklist

• Name the owner of the system and the owner of the decision.
• Verify “inspect maxmemory and policy” from the actual production or financial source.
• Exercise the failure described by “noeviction can turn memory pressure into write failures”.
• Reconcile the observed result with the evidence list above.
• Put an expiry and rollback condition on every exception.
• Monitor the user, security, reliability, or cash outcome—not only activity.
• Revisit dependencies when the underlying product, contract, or standard changes.

Make this control sustainable

Assign the owner closest to the enforcement point described in “compare logical memory, RSS, allocator fragmentation, container limit, and host pressure”, plus a backup who can execute the rollback. Review the control after a material release, supplier change, incident, financing event, or policy change that affects its assumptions. An alert is useful only when it names an action: inspect, throttle, revoke, reconcile, fail over, or escalate. Use the evidence measurements above to set thresholds from observed workload or financial behavior. Treat volatile policies fail expectations when many keys lack TTLs as a specific review trigger. Close temporary exceptions with an owner, expiry, compensating control, and proof that the normal path was restored.

Primary references and further verification

Use current Redis memory-optimization and eviction-policy documentation. Prefer sampled scans and offline analysis over blocking production commands.

For a current redis eviction troubleshooting decision, record the publication or effective date of the primary material and the version actually deployed or executed. Recheck vendor, standards-body, regulator, or accounting guidance when the product, protocol, vulnerability, or contract changes. Discovery summaries can point to an issue, but the decision record should link to the authoritative source and the organization’s own reproducible evidence.

Conclusion

The practical outcome is a control the team can explain and test: confirm persistence and data-loss expectations, then choose policy and capacity from workload behavior.. Keep the assumptions and exception path visible. That is more useful than a generic checklist because the next reviewer can reproduce the decision, see where it can fail, and reverse it safely.