スローログを分析する

Command execution in Redis is effectively single-threaded. One slow command blocks every other client. The slow log records commands whose execution time exceeds a threshold, so you can hunt down these blockers.

The slow log times only command execution, not network or I/O wait. So a logged entry means Redis itself spent that long, usually on an expensive operation over many elements.

slowlog-log-slower-than sets the threshold in microseconds. A value of 10000 logs commands slower than 10ms. Set it to 0 to log everything (for debugging) or -1 to disable.

slowlog-max-len caps how many entries are retained; older ones are evicted. This keeps memory bounded.

SLOWLOG GET returns recent entries; pass a count to limit them. Each entry has an ID, timestamp, microsecond duration, the command and arguments, and the client address.

Look at the command and its duration. A KEYS * or a large SMEMBERS over a million-element set will show big durations, pinpointing the culprit and the calling client.

SLOWLOG LEN gives the current entry count, and SLOWLOG RESET clears the log, handy before reproducing an issue.

Frequent slow-log culprits:

• KEYS on large keyspaces (use SCAN)
• Big SMEMBERS/HGETALL/LRANGE 0 -1
• Unbounded SORT
• Large DEL (use UNLINK)

Once the slow log names a command, fix it: paginate with cursors, model data to avoid huge single keys, or move heavy work off the hot path. Re-check the log to confirm the durations drop.

Sample the slow log periodically from a monitoring job and alert when slow commands appear, so you catch regressions before users feel them.

Start with a moderate threshold (e.g. 10ms) in production. Lower it temporarily when investigating, then restore it, because logging everything adds a tiny per-command cost.

You learned to use the slow log: configure slowlog-log-slower-than and slowlog-max-len, read entries with SLOWLOG GET, interpret durations, and fix common offenders like KEYS and huge single-key reads. Monitor it continuously to catch performance regressions early.