Redis Eviction Policy Tuning Prompt

You are a senior SRE and Redis expert who tunes eviction behavior for cache and data-store roles.

I will provide:
- The instance role (pure cache vs data store vs mixed)
- `CONFIG GET maxmemory*` and `INFO stats` (evicted_keys)
- Whether all keys have TTLs

Your job:

1. **Set `maxmemory`**: pick a ceiling below the box's RAM, leaving headroom for RSS overhead and COW during fork (RDB/AOF rewrite). ~25% headroom is a common start.
2. **Choose `maxmemory-policy`**:
   - `noeviction` (default): reject writes when full — correct for a data store you cannot lose keys from, but writes error.
   - `allkeys-lru` / `allkeys-lfu`: evict least-recently/frequently used across all keys — best for a pure cache.
   - `volatile-lru` / `volatile-lfu` / `volatile-ttl` / `volatile-random`: evict only keys that have a TTL. `volatile-ttl` evicts nearest-expiry first.
   - `allkeys-random` / `volatile-random`: cheap but blind.
3. **LRU vs LFU**: LFU (`allkeys-lfu`) resists cache pollution from one-off scans better; tune `lfu-log-factor` and `lfu-decay-time`.
4. **Sampling accuracy**: Redis eviction is approximate; raise `maxmemory-samples` (default 5) for closer-to-true LRU/LFU at CPU cost.
5. **Watch the signals**: `INFO stats` → `evicted_keys`, `keyspace_hits/misses`; `INFO memory` → `used_memory` vs `maxmemory`.
6. **Common trap**: `volatile-*` policies with keys that have NO TTL means Redis has nothing to evict and behaves like `noeviction` (OOM errors).
7. **Validate**: after changing, confirm evictions rise gracefully and writes stop erroring.

Mark DESTRUCTIVE: `CONFIG SET maxmemory-policy noeviction` on a full cache (writes begin failing), `CONFIG SET maxmemory 0` (removes the cap → OOM killer), `FLUSHALL`/`FLUSHDB`, and `KEYS *`/`DEBUG` on prod.

---

Instance role: [DESCRIBE]
maxmemory config: [PASTE]
All keys have TTL?: [YES/NO]

Why this prompt works

The single most common Redis outage is “writes started failing” — almost always a maxmemory/maxmemory-policy mismatch. This prompt separates the cache case (evict freely with allkeys-lru/lfu) from the data-store case (noeviction, but then you must size for growth), and catches the classic trap of a volatile-* policy on keys that have no TTL to evict.

How to use it

1. Declare the role first — cache vs data store decides the whole policy family.
2. Say whether every key has a TTL — this determines if volatile-* is even viable.
3. Paste evicted_keys so you know if eviction is already happening.
4. Share RAM size so maxmemory headroom advice is correct.

Useful commands

# Current settings and eviction rate
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy
redis-cli CONFIG GET maxmemory-samples
redis-cli INFO stats | grep -E 'evicted_keys|keyspace_hits|keyspace_misses'
redis-cli INFO memory | grep -E 'used_memory:|maxmemory:'

# Apply a cache-appropriate policy (persist to redis.conf too)
redis-cli CONFIG SET maxmemory 4gb
redis-cli CONFIG SET maxmemory-policy allkeys-lru
redis-cli CONFIG SET maxmemory-samples 10

# How many keys carry a TTL (volatile viability)
redis-cli INFO keyspace

Example config

# redis.conf — pure cache node
maxmemory 4gb
maxmemory-policy allkeys-lru
maxmemory-samples 10
# LFU tuning if you switch to allkeys-lfu
lfu-log-factor 10
lfu-decay-time 1

Common findings this catches

• noeviction on a cache → writes fail once full instead of evicting.
• volatile-lru with no TTLs → nothing evictable, effectively noeviction.
• maxmemory unset → grows until the OOM killer strikes.
• maxmemory too high → no fork headroom; RDB/AOF rewrite OOMs.
• Cache pollution → one-off scans evict hot keys; switch LRU → LFU.
• Low maxmemory-samples → poor eviction choices under pressure.

When to escalate

• A data store legitimately needs more than one node — plan clustering.
• Evictions dropping live data users depend on — the workload outgrew the box.
• Choosing durability vs eviction tradeoffs — align with the data owner.