Redis usually answers in well under a millisecond. Then, a few times an hour, every client times out at once for one or two seconds, and the dashboards show a flat line followed by a spike.
Redis executes commands on one main thread. One slow command blocks every other client until it finishes. Almost every Redis latency spike comes from a command, or a background operation, that monopolizes that thread.
Find the culprit
redis-cli SLOWLOG GET 20 # commands slower than slowlog-log-slower-than (10 ms default)
redis-cli LATENCY DOCTOR # after: CONFIG SET latency-monitor-threshold 100
redis-cli --latency-history # watch round-trip latency from the client side
redis-cli INFO commandstats # calls and usec_per_call per command
SLOWLOG records only the command's execution time, not time spent queued behind it, so one slow KEYS entry can explain a thousand client timeouts.
Culprit 1: KEYS * and other O(N) commands
KEYS pattern walks the entire keyspace. On 20 million keys that's seconds of total blackout. It's often hidden in admin tools, cleanup scripts and "delete everything matching session:*" code.
Use SCAN, which walks the keyspace in small batches between other clients' commands:
redis-cli --scan --pattern 'session:*' --count 1000 | xargs -n 500 redis-cli UNLINK
Other commands to be careful with on large data: SMEMBERS, HGETALL, LRANGE 0 -1 and ZRANGE 0 -1 on huge collections (use SSCAN, HSCAN, ZSCAN or bounded ranges), SORT, SUNION/SINTER over big sets, and FLUSHALL/FLUSHDB without ASYNC. Disable or rename dangerous commands in production (rename-command KEYS "", or ACLs with -@dangerous).
Culprit 2: big keys
A single hash with 5 million fields, or a 200 MB string, makes every operation on it slow, and it with frees memory on the main thread and blocks for a long time.
