Диагностика тормозов: slowlog, bigkeys, latency doctor

«Redis иногда тормозит» — самая частая жалоба. У этого диагноза семь типовых причин, и у каждой есть свой инструмент доказательства. Разбираем методику от симптома к причине.

SLOWLOG: кто именно медленный

CONFIG SET slowlog-log-slower-than 10000   # микросекунды = 10 мс
CONFIG SET slowlog-max-len 256
SLOWLOG GET 10
1) id, время, длительность(мкс), команда, клиент:порт, имя клиента
SLOWLOG LEN ; SLOWLOG RESET

Slowlog измеряет только время исполнения команды. Если его пусто, а клиент жалуется — проблема вне исполнения: сеть, fork-паузы, своп, клиентская очередь.

Семь типовых причин и их доказательства

Причина	Симптом	Как доказать
O(N)-команды по большим коллекциям	спорадические стопоры на 10–500 мс	SLOWLOG: KEYS/SMEMBERS/HGETALL/LRANGE на гигантах
Долгий fork (BGSAVE/AOF rewrite)	шипы раз в N минут/часов	INFO persistence → latest_fork_usec; сопоставить с расписанием save
Своп	всё постоянно медленное	mem_fragmentation_ratio < 1; free на хосте; dmesg
Eviction-шторм	латентность при полной памяти	INFO stats → evicted_keys дельта; INFO memory → maxmemory достигнут
Истечение пачек TTL	периодические провалы	latency monitor (event expire-cycle); джиттер TTL отсутствует
Big keys	спорадические стопоры при конкретных операциях	redis-cli --bigkeys/--memkeys; MEMORY USAGE подозреваемых
Сеть/клиент	сервер быстр, клиенты медленны	redis-cli --latency с хоста Redis (быстро?) vs из пода приложения (медленно?)

Latency monitor: встроенный следователь

CONFIG SET latency-monitor-threshold 10   # мс; фиксировать события дольше
LATENCY HISTORY fork          # история события "fork"
LATENCY HISTORY command
LATENCY DOCTOR                # автоматический разбор всех событий + рекомендации

LATENCY DOCTOR — недооценённая команда: она сама сопоставит fork-паузы с save-правилами, eviction с памятью и выдаст человеческий отчёт.

Сетевые измерения

redis-cli --latency            # PING-цикл с текущего хоста
redis-cli --latency-history    # то же, окнами по 15с
redis-cli --latency-dist       # ASCII-гистограмма распределения

Методика: запустите с хоста Redis и с хоста приложения. Разница = сеть/виртуализация. Если обе точки быстрые, а пользователи медленные — смотрите клиент: пулы, таймауты, десериализацию, GC-паузы приложения.

Разбор кейса (сквозной пример)

Симптом: раз в 5 минут p99 у всех подов подскакивает до 150 мс.

Slowlog пуст → исполнение команд не при чём;
INFO persistence: latest_fork_usec: 140000, save-правило save 300 10 → fork каждые ~5 минут. Совпадение найдено;
Решения: сократить датасет (разделить инстансы), переехать на AOF everysec с no-appendfsync-on-rewrite yes, ускорить диск, или перейти на >= 7 c multi-part AOF и разнесёнными rewrite;
Проверка: latency history за сутки — шипы исчезли.

Практика

Воспроизведите каждую из семи причин в лаборатории и «поймайте» её соответствующим инструментом (slowlog, fork_usec, своп — выкрутите vm.swappiness и залейте память и т.д.).
Напишите «playbook»: шаблон расследования с командами по шагам для дежурного инженера.
Запустите latency monitor на неделю в тестовом окружении под нагрузкой и разберите LATENCY DOCTOR.

Мини-квиз

1. Slowlog пуст, клиенты жалуются. Где искать? — Вне исполнения: fork, своп, сеть, eviction-шторм, клиентские пулы.

2. Как отличить сетевую проблему от серверной? — Замер --latency с хоста Redis и с хоста приложения.

3. Что покажет LATENCY DOCTOR при регулярных fork-паузах? — Свяжет их с save-правилами и размером датасета, посоветует пересмотреть конфигурацию.