A 1.5 second command
One thread, so this is dead time for every other client
1) 1) "command" 2) (integer) 1699000000 3) (integer) 250 4) (integer) 1500
Paste the output of redis-cli LATENCY LATEST. Before reading it, know this: the latency monitor is disabled by default, so an empty report means either no spikes or nothing recorded, and those look identical.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Analyze. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
One thread, so this is dead time for every other client
1) 1) "command" 2) (integer) 1699000000 3) (integer) 250 4) (integer) 1500
The report is empty, which usually means the monitor was never switched on
(empty array)
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
The monitor is disabled by default, so an empty report is also what a server with constant stalls produces.
Instead:CONFIG SET latency-monitor-threshold 100 first.
CONFIG SET is lost on restart, so the monitoring quietly stops after the next one.
Instead:Put it in redis.conf as well.
Fork cost scales with mapped memory and is inherent to saving. There is no setting that removes it.
Instead:Move saves to a replica, or reduce memory per instance.
It names the subsystem, not the command.
Instead:Use SLOWLOG for the specific command and its arguments.
Redis names the subsystem that stalled rather than the command that suffered, which is more useful once the names are familiar.
latency-monitor-threshold defaults to 0, which means the monitor records nothing at all. An empty LATENCY LATEST is therefore consistent with a perfectly healthy server and with a server that has been stalling for months. Set the threshold before concluding anything.
Redis forks for BGSAVE and for AOF rewrite, and the pause scales with how much memory the process has mapped. On virtualised hardware it is often several times worse than on bare metal. Moving saves to a replica removes it from the primary entirely.
A command event is dead time for every other client, because there is one thread. It is almost always KEYS, a full HGETALL or SMEMBERS, or a wide range query. SLOWLOG names the specific command; LATENCY only says that one was slow.
The first means a large number of keys expired at once, which is fixed by adding jitter to TTLs so they do not land in the same second. The second means the instance is at maxmemory and doing eviction work constantly, which is a sizing problem rather than a tuning one.
Only events above the threshold, only since the last LATENCY RESET, and only on this node. Latency the client experienced from network or from its own connection pool never appears here at all.