Skip to content
DevOps AI ToolKit
Newsletter
All prompts
AI for Redis Difficulty: Advanced ClaudeChatGPTCursor

Redis Big Key and Hot Key Analysis Prompt

Hunt down oversized keys and traffic-skewed hot keys that cause latency spikes, uneven cluster load, and blocking deletes — then fix them safely.

Target user
SREs debugging Redis latency and hotspots
Difficulty
Advanced
Tools
Claude, ChatGPT, Cursor

The prompt

You are a senior Redis performance engineer who diagnoses latency and load-skew problems caused by big keys and hot keys in production.

I will provide:
- `redis-cli --bigkeys` / `--hotkeys` output
- `SLOWLOG GET` entries and `INFO commandstats`
- `INFO latencystats`, `LATENCY LATEST`, and per-node CPU in a cluster
- Key patterns and access ratios you already know about

Your job:

1. **Separate the two failure modes** — they are different problems:
   - **Big keys**: a single large collection (multi-MB hash, list, set, or zset). They make `O(N)` commands slow, block on `DEL`, and cause large network payloads.
   - **Hot keys**: a single key taking a disproportionate share of ops/sec. In Cluster mode they overload one shard no matter how many shards you add, because one key = one slot = one node.
2. **Find big keys**:
   - `redis-cli --bigkeys` samples the largest key per type; `--memkeys` ranks by bytes.
   - Confirm with `MEMORY USAGE key SAMPLES 0` and `OBJECT ENCODING` / element counts (`HLEN`, `LLEN`, `SCARD`, `ZCARD`, `STRLEN`).
   - Flag any collection over a few thousand elements or a few hundred KB.
3. **Find hot keys**:
   - `redis-cli --hotkeys` (requires an LFU `maxmemory-policy`) surfaces the most-accessed keys.
   - Cross-reference `INFO commandstats` (calls, usec_per_call) and `MONITOR` (SHORT, sampled — it is expensive) on a replica.
   - In Cluster, map the key to its slot with `CLUSTER KEYSLOT key` and check that node's CPU.
4. **Explain the latency link**:
   - Big keys → `usec_per_call` climbs for `HGETALL`/`SMEMBERS`/`LRANGE 0 -1`/`ZRANGE`; a single `DEL` of a huge key blocks the event loop.
   - Hot keys → one shard saturates while others idle; network and CPU pin to one core.
5. **Fix big keys**:
   - Break one giant hash/zset into sharded sub-keys (`obj:{id}:part:N`) or a Cluster hash-tagged bucket set.
   - Replace `O(N)` full reads with `HSCAN`/`SSCAN`/`ZSCAN` cursors or ranged reads (`ZRANGE`, `LRANGE start stop`).
   - Delete big keys with `UNLINK` (async) not `DEL`; enable `lazyfree-lazy-user-del yes`.
6. **Fix hot keys**:
   - Add a client-side / local cache layer for read-hot keys to absorb reads before Redis.
   - Replicate the hot key to N suffixed copies (`config:v1..vN`) and pick one at random on read to spread load across slots/nodes.
   - For hot counters, shard the counter and sum on read.
7. **Re-measure**: compare `SLOWLOG`, `usec_per_call`, and per-node CPU before/after.

Mark DESTRUCTIVE / RISKY: `MONITOR` and `--bigkeys`/`--hotkeys` add real load — prefer a replica or off-peak. `DEL` on a multi-GB key stalls the server; use `UNLINK`. `KEYS *` blocks; use `SCAN`.

---

--bigkeys/--hotkeys: [PASTE]
SLOWLOG / commandstats: [PASTE]
Cluster topology & CPU: [DESCRIBE]

Run this prompt with AI

Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.

Why this prompt works

Big keys and hot keys look similar in a latency graph but need opposite fixes: big keys are a data-modeling problem (one key holds too much), while hot keys are a distribution problem (one key gets too much traffic). This prompt forces you to identify which one you have with the exact redis-cli tooling, then apply the matching remedy — sharding the value vs. spreading the reads.

How to use it

  1. Run --bigkeys and --memkeys on a replica and paste the top offenders.
  2. Run --hotkeys (needs an LFU policy) and paste the results.
  3. Paste SLOWLOG GET 25 and INFO commandstats so the latency link is concrete.
  4. Share Cluster topology and per-node CPU if hotspotting is suspected.

Useful commands

# Big keys
redis-cli --bigkeys
redis-cli --memkeys
redis-cli MEMORY USAGE cart:98213 SAMPLES 0
redis-cli OBJECT ENCODING cart:98213
redis-cli HLEN cart:98213

# Hot keys (requires allkeys-lfu / volatile-lfu)
redis-cli CONFIG SET maxmemory-policy allkeys-lfu
redis-cli --hotkeys

# Latency evidence
redis-cli SLOWLOG GET 25
redis-cli INFO commandstats | sort -t= -k2 -rn | head
redis-cli LATENCY LATEST

# Map a hot key to its slot/node
redis-cli CLUSTER KEYSLOT config:global

Common findings this catches

  • One multi-MB hash read with HGETALL → convert to HSCAN or shard the hash.
  • A giant list read via LRANGE 0 -1 → use bounded ranges.
  • A single config/feature-flag key at 40k ops/sec → local-cache or fan-out replicas.
  • DEL biglist stalling the loop → switch to UNLINK.
  • One Cluster shard at 95% CPU while peers idle → hot key, not under-provisioning.

When to escalate

  • Hot key traffic that a local cache cannot absorb — needs an architectural read path.
  • Big keys that must stay atomic — revisit whether Redis is the right store.
  • Persistent slot imbalance after key redistribution — capacity and topology review.

Related prompts

More Redis prompts & error guides

Browse every Redis prompt and troubleshooting guide in one place.
Free download · 368-page PDF

Reading prompts? Get all 500 in one free PDF

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.