To diagnose a Redis system, capture latency, memory, client, keyspace, persistence, and host evidence before changing configuration or restarting anything.
Redis is fast enough that a slow request often gets blamed on the wrong layer. The useful question is not whether Redis is slow; it is which queue, command, key, client, or host condition is making this Redis workload slow right now.
Table of contents
- Start with a five-minute Redis snapshot
- Separate latency, memory, and connection failures
- Find expensive commands and dangerous keys
- Check persistence, the host, and the network
- Turn the incident into a durable fix
- How this fits the rest of the stack
- FAQ
Start with a five-minute Redis snapshot
Begin with timestamps and a symptom: elevated p95 latency, timeouts, rejected connections, memory alarms, or an unavailable primary. Record the affected application route and the first bad minute. A dashboard without a time boundary is just a collection of colourful suspicions.
Use read-only commands first. PING proves the server can answer one tiny request; it does not prove the workload is healthy. INFO, SLOWLOG, LATENCY, and client statistics reveal much more while keeping the investigation controlled.
redis-cli --latency-history
redis-cli INFO memory
redis-cli INFO stats
redis-cli INFO clients
redis-cli SLOWLOG GET 20Separate latency, memory, and connection failures
Latency can come from slow commands, network round trips, fork activity, disk writes, swapping, CPU saturation, or a client that sends commands serially. Compare the Redis latency baseline with application timing. If Redis answers locally in a millisecond but the application waits 400 milliseconds, inspect the network path and connection pool before tuning Redis.
For memory incidents, compare used_memory, used_memory_rss, maxmemory, evictions, and fragmentation. Rising RSS alone is not proof of a leak. Evictions with a falling hit rate, however, tell a much sharper story: the cache is too small, the policy is wrong, or the key set has changed.
Find expensive commands and dangerous keys
The slow log reports command execution time inside Redis, excluding network transfer. That makes it useful, but not complete. Pair it with command statistics and application traces. A command may be individually quick yet overwhelm the server when called thousands of times per request.
Use --bigkeys or sampled scans rather than blocking keyspace commands. Look for oversized collections, hot keys, missing expirations, and patterns that create unbounded cardinality. Do not run KEYS * on a busy production database because an incident does not need a second incident as a side quest.
redis-cli --bigkeys
redis-cli INFO commandstats
redis-cli --scan --pattern 'session:*' | headCheck persistence, the host, and the network
AOF fsync, snapshots, and fork operations can expose slow disks or insufficient memory headroom. Check persistence status, recent background-save failures, host I/O wait, swap activity, and transparent huge pages. Redis cannot out-configure a host that is paging its working set to disk.
Then inspect client count, blocked clients, rejected connections, reconnect storms, DNS resolution, and security-group or firewall changes. In clustered deployments, add replication lag, link state, slot ownership, and MOVED or ASK errors to the timeline.
Turn the incident into a durable fix
Fix the narrowest verified cause. That may mean removing an accidental O(N) command, bounding a collection, pipelining requests, resizing memory, changing eviction policy, adding connection-pool limits, or moving persistence to appropriate storage. Change one variable at a time and compare the same measurements taken at the start.
Keep a small Redis runbook with normal latency, memory headroom, client limits, persistence expectations, owners, and rollback commands. The next alert should begin with known baselines, not a team rediscovering INFO while the status page waits.
How this fits the rest of the stack
If the diagnosis points to an undersized service or a stack with hidden supporting costs, model the Redis service, application, database, and bandwidth together in the RunxBuild hosting calculator. Then open the RunxBuild dashboard when the deployment shape is clear.
Useful related references:
- ioredis vs node-redis: Which to Ship With
- Redis Pipeline: How to Batch Commands, When to Use It, and Why It Is Not the Same as a Transaction
- Redis Persistence: RDB, AOF, and the Right Defaults
- Databases on RunxBuild
FAQ
What is the first command to run when Redis is slow?
Start with redis-cli --latency-history and focused INFO sections. PING is useful for reachability, but it cannot identify memory pressure, slow commands, blocked clients, or persistence stalls.
Is the Redis MONITOR command safe in production?
Use it only briefly and cautiously. MONITOR streams every processed command and adds overhead while potentially exposing sensitive values. Prefer slow logs, command statistics, sampled tracing, and application telemetry first.
How do I know whether Redis needs more memory?
Look for sustained proximity to maxmemory, evictions, hit-rate changes, fragmentation, and the intended role of the data. More memory helps only when the workload and eviction evidence show capacity pressure.
Should I restart Redis to clear an incident?
A restart may temporarily remove symptoms and erase useful evidence. Restart only when availability requires it and you understand persistence, replication, failover, and data-loss consequences.
What should a Redis alert include?
Include the affected instance, time window, latency, memory and eviction state, client counts, persistence status, replication state, and a link to the application trace that experienced the symptom.