Ovalk
All troubleshooting guides
Cache / RedisUpdated About 2 min read · execution time varies

Redis memory pressure and eviction: distinguish policy, hot keys, and TTL debt

Increasing maxmemory is not a root-cause fix. Inspect eviction policy, key lifetimes, large values, and workload growth before changing capacity.

Maintained by Kevin · Ovalk

Scope and prerequisites

Redis cache or data service. ACLs and managed-service policies may block CONFIG or diagnostic commands.

Establish whether any keys are authoritative data. Use the application's configured TLS/authentication connection and read-only diagnostics; avoid putting secrets in commands.

Examples are not commands to paste blindly. Replace example domains, paths, service names and UPPERCASE placeholders. Gather evidence first; reloads, rollbacks, prune operations and job executions change state and require an approved impact and recovery plan. Never share credentials or unredacted logs.

Common symptoms

  • Writes fail with OOM command not allowed.
  • Evicted keys rise and cache hit rate falls.
  • RSS is much larger than used_memory.

1. Read memory and eviction state

Collect used memory, maxmemory, fragmentation, keyspace, and eviction metrics. First establish whether the instance is a disposable cache or holds durable data—the acceptable policy is different.

redis-cli INFO memory
redis-cli INFO stats | grep -E "evicted|keyspace"
redis-cli CONFIG GET maxmemory-policy

2. Find the growth source safely

Sample key prefixes, TTLs, and value sizes. Avoid unbounded KEYS scans on large production instances; use incremental scanning or a replica for deeper analysis.

redis-cli --scan --pattern "*" | head -n 50
redis-cli INFO keyspace

3. Choose a reversible mitigation

For a cache, reduce write pressure, shorten verified-expirable data, or add sharding. For durable data, stop the faulty writer and plan migration instead of allowing silent eviction.

redis-cli SLOWLOG GET 20
redis-cli INFO commandstats

Interpret the evidence

ObservationWhat to check next
High evicted_keys counterCompare its change over a timed interval and the hit rate; a lifetime counter alone does not establish current pressure.
High RSS versus used_memoryInspect fragmentation, allocator behaviour and buffers. Do not assume all RSS is an application leak.
No TTL on sampled keysDetermine whether this is intentional durable data or a cache-writer defect before adding expiry.

Illustrative diagnosis

A hypothetical example to explain the reasoning, not a reported customer incident or a claim of testing on your stack.

Writes start failing under a volatile eviction policy, but most keys have no TTL. There may be no eligible keys to evict. Compare INFO keyspace with a bounded sample of the intended cache prefix. Fix the writer's lifecycle rule or plan capacity; changing to allkeys eviction can silently remove data that was never meant to be disposable.

Verify recovery

  • Verify writes, hit rate and application latency under normal traffic without unexpected key loss.
  • Track memory, eviction and expiry rates together. Confirm enough process memory remains for replication and persistence overhead.

Rollback and stopping point

Record original policy and limits. Reverting an eviction policy cannot bring back evicted keys; confirm reconstruction or backups before permitting deletion.

Prevention and long-term repair

  • Require TTLs and naming conventions for cache keys.
  • Estimate peak-memory cost for new keys and fields before release.
  • Monitor hit rate, eviction, fragmentation, and hot commands.

References and corrections

Use the documentation for your installed version. The references below explain the underlying behavior; commands still need environment-specific validation.

Report a correction to Kevin — include the page URL, version and a redacted reproduction. See our editorial policy.