A Redis instance serves sub-millisecond responses most of the time but shows recurring multi-hundred-millisecond spikes. Walk through the causes you would investigate and the evidence that distinguishes them.

## Framing Redis processes commands on a single thread, so *any* pause becomes everyone's pause. Diagnosing spikes is therefore a matter of asking: was the thread busy doing work (a command), or was it prevented from running (the OS or a system call)? Each family has distinct evidence, and naming the evidence is what separates a senior answer from a list of guesses. ## Family 1 — a command occupied the thread **Big-O over big values.** `KEYS *` scans the whole keyspace; `HGETALL`/`SMEMBERS`/`LRANGE 0 -1` materialise an entire collection; `SORT`, `ZUNIONSTORE`, `SINTERSTORE` over large sets are worse. Ten milliseconds of CPU is a lifetime when the median command is 50 microseconds. **Freeing memory is work too.** `DEL` of a 5-million-field hash frees every element synchronously. `UNLINK` (and `lazyfree-lazy-*` settings, plus `FLUSHALL ASYNC`) hands that reclamation to a background thread instead. **Scripts.** Lua scripts and Functions execute atomically; the whole script is one blocking unit. A loop over a large set inside a script is indistinguishable from a slow command, except it may not even be obvious from the SLOWLOG argument list. **Big payloads and huge pipelines.** Multi-megabyte values cost in allocation, copying, and reply construction; a client that pipelines 100k commands hands the server one enormous unit of work and can also inflate the output buffer. Evidence: `SLOWLOG GET` shows an entry of the right magnitude; `INFO commandstats` (`usec_per_call`) shows the mildly-slow-but-constant case that SLOWLOG never records; `LATENCY HISTORY command`. ## Family 2 — fork stalls RDB snapshots and AOF rewrites are produced by forking the process and letting the child write while the parent keeps serving, relying on copy-on-write. The **`fork()` call itself** is not free: the kernel must copy page tables, and the cost grows roughly with the amount of memory mapped. On a 40GB instance it can be hundreds of milliseconds; with **transparent huge pages (THP)** enabled it is dramatically worse, and THP also inflates copy-on-write memory afterwards, which is why Redis logs a warning recommending it be disabled. Evidence: `INFO stats: latest_fork_usec`; `INFO persistence: rdb_bgsave_in_progress`, `aof_rewrite_in_progress`, `rdb_last_bgsave_time_sec`; `LATENCY HISTORY fork`; and periodicity that matches the `save` directives or an `auto-aof-rewrite-percentage` trigger. Mitigations: disable THP; shard so each instance holds less memory; take snapshots on a replica instead of the primary; tune or remove `save` points if RDB is not your durability story. ## Family 3 — memory pressure **Swapping is the worst case.** Redis assumes memory access is nanoseconds. If the OS pages part of the dataset to disk, a random access becomes a disk seek while the single thread waits, and latency goes from microseconds to tens of milliseconds unpredictably. Check the process's swap usage directly (on Linux, `/proc/<pid>/smaps`); `INFO memory` also reports `used_memory_rss` and `maxmemory_policy`. The fix is capacity, not tuning: keep the dataset comfortably below RAM, and give room for copy-on-write during saves and for replication buffers. **Eviction cycles.** Running at `maxmemory` means every write may first evict. With approximated LRU/LFU sampling and large values to free, that work lands on the request path. Evidence: `LATENCY eviction-cycle` / `eviction-del`, `evicted_keys` climbing in `INFO stats`. ## Family 4 — expiry cohorts Redis expires keys lazily (on access) and actively (a periodic sampling cycle). If a batch job writes two million keys with `EX 3600` in the same minute, an hour later the active cycle faces a mountain of deletions in a short window. Evidence: `LATENCY expire-cycle`, plus a spike in `expired_keys` at a regular interval one TTL after a known job. Fix: jitter TTLs with a random offset so the cohort dissolves. ## Family 5 — disk and durability `appendfsync always` makes writes wait for an fsync — correct if you need it, but it is a latency decision, not a free one. Even `everysec` can block when an AOF rewrite is saturating the same disk (`aof-write-active-child`, `aof-rewrite-diff-write` events, and `aof_delayed_fsync` in `INFO persistence`). Network-attached storage with variable latency amplifies all of this. ## Family 6 — the host CPU steal on a shared or burstable instance, a noisy neighbour, NUMA effects, or aggressive power management can pause the process for milliseconds with no Redis-side evidence at all. `redis-cli --intrinsic-latency 60` run on the server reports the floor. If the floor is already 5ms, stop tuning Redis. ## Family 7 — clients and connections Connection storms (no pooling, TLS handshakes per request), slow consumers filling client output buffers, or `MONITOR` left running in a terminal all show up as latency. `INFO clients` (`connected_clients`, `blocked_clients`, `client_recent_max_output_buffer`) and `CLIENT LIST` locate these. ## The discriminating move Ask first: **is it periodic?** Regular spikes strongly imply a save/rewrite fork, a TTL cohort, or a cron job. Irregular spikes correlated with traffic imply an expensive command or eviction. Constant elevation with no spikes implies the host floor or the network. That single question routes you to the right evidence in one step.