KEYS in production
The command that blocks the whole server while it walks the keyspace
1) 1) (integer) 14
2) (integer) 1700000000
3) (integer) 152000
4) 1) "KEYS"
2) "user:*"
5) "10.0.0.7:53892"Paste redis-cli SLOWLOG GET output. Commands are grouped and ranked by total blocking time, and each carries the specific reason that command tends to be slow.
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.
The command that blocks the whole server while it walks the keyspace
1) 1) (integer) 14
2) (integer) 1700000000
3) (integer) 152000
4) 1) "KEYS"
2) "user:*"
5) "10.0.0.7:53892"HGETALL against a hash big enough to matter, with the cheaper alternative
1) 1) (integer) 22
2) (integer) 1700000100
3) (integer) 48000
4) 1) "HGETALL"
2) "session:index"These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
It is a ring buffer of slowlog-max-len entries, 128 by default. On a busy instance that can be a few seconds of history.
Instead:Raise slowlog-max-len, and lower slowlog-log-slower-than while investigating.
It measures execution only, not reading the request or writing the reply. A command returning a large result takes far longer in wall-clock terms, and that time also blocks the server.
Instead:Compare against client-side latency. A gap between them points at result size or network.
It only controls when the server starts answering others with BUSY. The script keeps running, and once it has written anything the only exit is SHUTDOWN NOSAVE.
Instead:Keep scripts short and bounded. Do not use them for bulk work.
Redis executes commands one at a time on a single thread. A slow command does not merely have high latency for the client that issued it; it adds that latency to every other client waiting behind it.
It keeps slowlog-max-len entries, 128 by default, and discards older ones. On a busy instance that can be a few seconds of history, so an empty or short slow log is not evidence that nothing is slow. Raise the length, and lower slowlog-log-slower-than from its 10,000 microsecond default when hunting something smaller.
It measures execution only, not the time spent reading the request from the socket or writing the reply back. A command that returns a large result can take far longer in wall-clock terms than the slow log shows, and that transmission time also blocks the server.
KEYS scans the entire keyspace. HGETALL and SMEMBERS return an entire collection. LRANGE key 0 -1 returns an entire list. DEL of a huge collection frees every element synchronously, which UNLINK avoids by doing it in a background thread. None of these are bugs; they are the documented cost, met with a larger collection than expected.
A Lua script blocks for its entire duration. lua-time-limit does not stop it; it only controls when the server starts answering other clients with BUSY, and at that point the only remedies are SCRIPT KILL or, if the script has written anything, SHUTDOWN NOSAVE.
SLOWLOG GET has no stable machine-readable format, so unusual client output may not parse. The log records what was slow, not why the data grew, and it cannot show commands that were fast individually but arrived in overwhelming volume. LATENCY HISTORY and LATENCY DOCTOR cover the events that are not command execution at all, such as fork time during BGSAVE.