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

Redis Capacity Planning and Forecasting Prompt

Forecast Redis memory, connection, and throughput headroom — accounting for RSS overhead, replication buffers, fork COW, and growth — to decide when to scale up, add replicas, or shard.

Target user
SREs sizing and forecasting Redis capacity
Difficulty
Advanced
Tools
Claude, ChatGPT, Cursor

The prompt

You are a senior SRE who does capacity planning and growth forecasting for Redis.

I will provide:
- `INFO memory`, `INFO stats`, `INFO clients`, `INFO replication`, and host/container RAM + CPU
- Key-count and dataset growth over the last N weeks
- The role (cache with eviction vs durable datastore) and SLOs

Your job:

1. **Separate dataset from overhead**: `used_memory` (logical dataset) is not the number that OOMs you — `used_memory_rss` is. Account for allocator overhead (`mem_fragmentation_ratio`), replication backlog + client output buffers, and the **fork copy-on-write** headroom needed during RDB/AOF rewrite (can transiently need a large fraction of the dataset extra). Recommend keeping `maxmemory` well below RAM so a fork doesn't invoke the OOM killer.
2. **Forecast memory growth**: from key-count/dataset trend, project weeks-to-`maxmemory`. For a datastore this is a hard wall (`noeviction` → OOM errors); for a cache, project when hit ratio degrades as the working set outgrows the box.
3. **Size connections**: compare peak `connected_clients` and `blocked_clients` to `maxclients`; account for connection-pool size × app instances. Warn about running out of client slots (max-number-of-clients).
4. **Size throughput**: `INFO stats` ops/sec, `instantaneous_ops_per_sec`, network bytes; check CPU (Redis is single-threaded for command execution — one core is the ceiling unless I/O threads help network only).
5. **Recommend the scaling move**: vertical (bigger box) first for a single hot dataset; read replicas for read scaling; **Cluster/sharding** only when one node's memory or single-core CPU is the true bottleneck. State the trigger metric and threshold for each.
6. **Set alert thresholds**: `used_memory`/`maxmemory` ratio, RSS/RAM ratio, `connected_clients`/`maxclients`, CPU, replication lag — with headroom to act before saturation.

Mark DESTRUCTIVE or risky: setting `maxmemory` too close to RAM (fork OOM kill), sizing on `used_memory` while ignoring RSS/COW, and adding replicas expecting write scaling (they scale reads only).

---

INFO + host specs: [PASTE]
Growth over last N weeks: [DESCRIBE]
Role + SLOs: [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

Redis capacity surprises come from the numbers people don’t watch: RSS versus logical used_memory, the fork copy-on-write spike during persistence, and the single-core execution ceiling. This prompt forecasts against the metric that actually fails you, distinguishes cache vs datastore growth, and names the specific trigger for scaling up, adding replicas, or sharding.

How to use it

  1. Provide RSS and RAM, not just used_memory — the gap is your real headroom.
  2. Give a multi-week growth trend — a point-in-time snapshot can’t forecast.
  3. State the role — cache degrades gracefully; a noeviction datastore hits a hard wall.

Useful commands

# The four capacity dimensions
redis-cli INFO memory | grep -E 'used_memory_human|used_memory_rss_human|maxmemory_human|mem_fragmentation_ratio'
redis-cli INFO clients | grep -E 'connected_clients|blocked_clients|maxclients'
redis-cli INFO stats | grep -E 'instantaneous_ops_per_sec|total_net_input_bytes|evicted_keys'
redis-cli INFO replication | grep -E 'connected_slaves|master_repl_offset'

# CPU: Redis command execution is single-threaded
redis-cli INFO cpu

# Growth signal: track over time
redis-cli DBSIZE

Example forecast sketch

used_memory      = 6.0G   (logical dataset)
used_memory_rss  = 7.9G   (frag 1.32) — this is what must fit
fork COW headroom~= +30% of dataset during BGSAVE
=> plan RSS + COW ~= 10.4G peak; maxmemory 8G on a 16G box leaves room
growth           = +0.35G/week => ~5.7 weeks to 8G maxmemory (datastore wall)
=> trigger: at used/maxmemory > 0.75 (6G) start the shard/scale-up work

Common findings this catches

  • Planning on used_memory → fork OOM under RDB/AOF rewrite.
  • maxmemory near RAM → no COW headroom.
  • Replicas expected to scale writes → they don’t.
  • Pool × instances > maxclients → connection exhaustion on deploy.
  • Single-core ceiling ignored → CPU-bound before memory-bound.

When to escalate

  • One node’s single core or memory is the true bottleneck — plan Cluster sharding.
  • Growth is exponential, not linear — revisit data model and TTLs before buying hardware.

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.