Redis Memory Optimization Prompt

You are a senior SRE and Redis expert who profiles and shrinks Redis memory footprints in production.

I will provide:
- `INFO memory` output and `MEMORY STATS`
- Sample keys and their types/sizes
- Growth trend and instance size

Your job:

1. **Read the memory picture**:
   - `used_memory` (dataset), `used_memory_rss` (OS resident), `mem_fragmentation_ratio`.
   - A ratio well above 1.0 = fragmentation; below 1.0 = swapping (bad).
2. **Find big keys and heavy patterns**:
   - `redis-cli --bigkeys` and `redis-cli --memkeys` sample the keyspace.
   - `MEMORY USAGE key` for exact per-key bytes.
3. **Check encodings** (`OBJECT ENCODING`):
   - Small collections use compact forms: `listpack` (hash/list/zset), `intset`/`listpack` (set), `embstr`/`int` (string).
   - Large ones convert to `hashtable`/`skiplist` — much bigger. Tune `hash-max-listpack-entries`, `set-max-intset-entries`, `zset-max-listpack-entries`, etc.
4. **Reduce footprint**:
   - Group small strings into hashes (one key per object beats N tiny keys — less overhead).
   - Shorten key names and field names.
   - Use HyperLogLog for approximate counts; bitmaps for dense flags.
   - Set TTLs so cold data expires.
5. **Fragmentation**:
   - Enable `activedefrag yes` and tune `active-defrag-*` thresholds, or restart during a window.
6. **Verify eviction fit**: confirm `maxmemory` and `maxmemory-policy` match the workload (cache vs data store).
7. **Re-measure**: compare `MEMORY STATS` before/after; watch `dataset.bytes` and `overhead.total`.

Mark DESTRUCTIVE: `FLUSHALL`/`FLUSHDB`, `KEYS *` and `--bigkeys` on a hot prod primary during peak (sampling still adds load), `DEBUG RELOAD`/`DEBUG SEGFAULT`, and `CONFIG SET maxmemory 0` (removes the cap).

---

INFO memory: [PASTE]
Sample keys: [DESCRIBE]
Growth/instance size: [DESCRIBE]

Why this prompt works

Redis memory blowups almost always trace to one of three causes: too many tiny keys (per-key overhead), collections that crossed a listpack/intset threshold into hashtable/skiplist encoding, or fragmentation. This prompt makes you measure each with the exact commands, then apply the specific config knob or modeling change that fixes it — instead of just buying a bigger instance.

How to use it

1. Paste INFO memory and MEMORY STATS for the real numbers.
2. Run --bigkeys on a replica and share the top offenders.
3. List representative key patterns so encoding advice is concrete.
4. State the instance size so maxmemory guidance fits.

Useful commands

# Overall memory picture
redis-cli INFO memory | grep -E 'used_memory:|used_memory_rss:|mem_fragmentation_ratio|maxmemory:'
redis-cli MEMORY STATS
redis-cli MEMORY DOCTOR

# Find heavy keys (run on a replica or off-peak)
redis-cli --bigkeys
redis-cli --memkeys
redis-cli MEMORY USAGE session:abc123

# Check encoding of a suspect key
redis-cli OBJECT ENCODING user:1        # listpack vs hashtable

# Current thresholds
redis-cli CONFIG GET 'hash-max-listpack-*'
redis-cli CONFIG GET 'zset-max-listpack-*'

Example config

# redis.conf — memory ceiling, eviction, encodings, defrag
maxmemory 6gb
maxmemory-policy allkeys-lru

# Keep small collections in compact encodings
hash-max-listpack-entries 128
hash-max-listpack-value 64
zset-max-listpack-entries 128
zset-max-listpack-value 64
set-max-intset-entries 512
set-max-listpack-entries 128
list-max-listpack-size 128

# Active defragmentation
activedefrag yes
active-defrag-ignore-bytes 100mb
active-defrag-threshold-lower 10
active-defrag-threshold-upper 100

Common findings this catches

• Millions of tiny string keys → high per-key overhead; consolidate into hashes.
• Collection past threshold → hashtable/skiplist encoding bloats memory.
• High fragmentation ratio → enable activedefrag or restart.
• Ratio < 1.0 → swapping; the box is under-provisioned.
• No TTLs on cold data → memory grows unbounded.
• Giant sets used for counting → replace with HyperLogLog.

When to escalate

• Sustained growth after optimization — capacity planning and sharding.
• Fragmentation that defrag cannot reclaim — needs a restart/failover window.
• Memory pressure causing evictions of live data — revisit the data model.