Почему Redis использует высокую загрузку ЦП? Методы отладки и оптимизации

Высокая загрузка ЦП в Redis обычно означает одно из трех: Redis выполняет слишком много командных операций на основном пути выполнения, фоновые задачи, такие как персистентность, создают дополнительное давление, или клиенты отправляют трафик в форме, которую Redis не может эффективно обработать. Решение зависит от того, какая из этих причин верна.

Не начинайте с перезапуска Redis, если только сервис уже не падает. Перезапуск может устранить симптом и стереть улики. Начните с захвата задержки команд, набора команд, количества клиентов, состояния персистентности и загрузки ЦП хоста. Эти факты покажут вам, есть ли у вас плохая команда, плохой шаблон трафика, перегруженное одно ядро или шумный хост.

Понимание архитектуры Redis и загрузки ЦП

Redis часто описывают как однопоточный, что в основном верно для выполнения команд, но современный Redis также может использовать фоновые потоки и опциональную многопоточность ввода-вывода. Практический смысл остается тем же: команда, которая выполняется слишком долго, может задерживать других клиентов, и одного насыщенного ядра может быть достаточно для создания видимой задержки, даже если на машине есть простаивающие ЦП в других местах.

Ключевые факторы, влияющие на загрузку ЦП Redis

Распространенными причинами являются дорогие команды, большие значения, Lua-скрипты, слишком много маленьких команд, отправляемых по одному круговому пути за раз, интенсивное переключение соединений, активность персистентности и давление памяти, которое заставляет ядро работать интенсивнее, чем ожидает Redis.

Отладка высокой загрузки ЦП

Прежде чем оптимизировать, необходимо точно определить источник нагрузки. Инструменты мониторинга и встроенные команды Redis необходимы для диагностики.

1. Использование команд `INFO` и `LATENCY`

Команда INFO предоставляет снимок состояния сервера. Сосредоточьтесь на разделе ЦП и статистике команд.

redis-cli INFO cpu

Смотрите на скорость изменения, а не только на абсолютные значения. Быстрое увеличение used_cpu_user часто указывает на обработку команд. Быстрое увеличение used_cpu_sys может указывать на работу ядра, такую как сетевые операции, управление памятью или активность, связанную с диском.

Инструменты задержки показывают классы событий, которые наблюдал Redis:

redis-cli LATENCY LATEST
redis-cli LATENCY DOCTOR

2. Выявление медленных команд с помощью `SLOWLOG`

Медленный журнал Redis записывает команды, превышающие указанное время выполнения. Это ваш самый прямой инструмент для поиска плохо работающих операций.

Медленный журнал Redis записывает команды, время выполнения которых превышает порог. Он не включает сетевое время или время ожидания в пуле клиентов, поэтому его лучше использовать вместе с метриками задержки приложения.

Пример конфигурации:

slowlog-log-slower-than 1000
slowlog-max-len 1024

Получение журнала:

redis-cli SLOWLOG GET 10

Проверьте имя команды, имена ключей и продолжительность. Если KEYS, большие HGETALL, огромные SMEMBERS, широкие диапазоны отсортированных наборов или Lua-скрипты доминируют в журнале, проблема, вероятно, связана с приложением.

3. Мониторинг сетевой активности и активности клиентов

MONITOR заманчив во время инцидента, но он дорог на загруженном сервере. Предпочитайте INFO commandstats, INFO clients, медленный журнал, метрики клиентской библиотеки и выборку с реплики, если она у вас есть.

Полезные команды:

redis-cli INFO commandstats
redis-cli INFO clients
redis-cli CLIENT LIST

Если объем команд удвоился после развертывания, вы можете увидеть это в счетчиках cmdstat_get, cmdstat_hgetall или аналогичных. Если клиенты постоянно подключаются и отключаются, исправьте пулинг перед настройкой Redis.

Распространенные причины и стратегии оптимизации

Как только вы определили проблемные команды или процессы, примените целенаправленные методы оптимизации.

1. Устранение блокирующих команд

Самые быстрые победы обычно достигаются за счет удаления команд, которые заставляют Redis обходить огромное пространство ключей или сериализовать огромное значение.

Неэффективная команда	Почему вызывает высокую загрузку ЦП	Оптимизация / Альтернатива
`KEYS *`	Сканирует все пространство ключей. O(N).	Используйте `SCAN` итеративно или реструктурируйте доступ к данным.
`FLUSHALL` / `FLUSHDB`	Удаляет каждый ключ, если не используется асинхронный режим.	Используйте осторожное удаление с областью действия, `UNLINK` или асинхронную очистку только когда это уместно.
`HGETALL`, `SMEMBERS` (на очень больших наборах)	Извлекает всю структуру в память и сериализует ее.	Используйте `HSCAN`, `SSCAN` или разбейте большие структуры на более мелкие ключи.

Используйте UNLINK вместо DEL для очень больших ключей. DEL освобождает память синхронно. UNLINK удаляет ключ из пространства ключей и освобождает память асинхронно, что обычно уменьшает видимую задержку при больших удалениях.

# Вместо DEL large_key
UNLINK large_key

2. Оптимизация персистентности (RDB и AOF)

Снимки RDB и перезаписи AOF используют фоновые дочерние процессы и все еще могут влиять на родительский процесс через стоимость fork, копирование при записи, пропускную способность диска и конкуренцию за ЦП.

Снимки RDB: Если вы часто сохраняете (например, каждую минуту), повторные вызовы fork() будут вызывать повторяющиеся скачки ЦП. Уменьшите частоту автоматических сохранений.
Перезапись AOF: Перезапись AOF (BGREWRITEAOF) также требует много ресурсов. Redis пытается оптимизировать это, выполняя минимальный ввод-вывод, но загрузка ЦП будет расти во время процесса.

Если персистентность совпадает со скачками ЦП, проверьте INFO persistence и метрики диска хоста. Вы можете уменьшить частоту RDB, запланировать тяжелые резервные копии вдали от пиков трафика, оставить больше свободной памяти или улучшить хранилище. Приостановка персистентности может снизить нагрузку, но также увеличивает риск потери данных, поэтому это должно быть осознанным операционным решением.

3. Обработка фрагментации памяти и подкачки

Хотя проблемы с памятью часто связаны с высоким использованием памяти, серьезная фрагментация памяти или, что еще хуже, начало подкачки данных Redis на диск (трешинг) операционной системой резко увеличат загрузку ЦП, поскольку ядро борется за управление памятью.

Проверка подкачки: Используйте инструменты ОС (vmstat, top), чтобы проверить, активно ли система подкачивает страницы памяти, принадлежащие процессу Redis.
Коэффициент фрагментации памяти: Проверьте mem_fragmentation_ratio в INFO memory. Высокий коэффициент является признаком того, что поведение аллокатора может тратить память, но подтвердите это с помощью RSS, размера набора данных и метрик памяти хоста.

Если происходит подкачка, уменьшите набор данных, снизьте maxmemory, переместите работу с хоста или добавьте память. Redis не предназначен для хорошей работы, когда его горячий набор данных выгружается на диск.

4. Оптимизация сети и конвейеризация

Если загрузка ЦП отслеживает большое количество маленьких команд, проблема может заключаться в накладных расходах на команды и сетевом переключении, а не в одной очевидно медленной команде.

Конвейеризация позволяет клиенту отправлять несколько команд без ожидания ответа после каждой. Это уменьшает количество круговых путей и может повысить пропускную способность для массовых операций записи или чтения. Ограничивайте размер пакетов конвейера; конвейер с тысячами тяжелых команд может создать свой собственный скачок задержки.

Лучшие практики для устойчивой производительности

Чтобы предотвратить будущие скачки ЦП, примите следующие архитектурные и конфигурационные лучшие практики:

Используйте UNLINK для ключей, которые могут быть большими.
Замените KEYS на SCAN, а полное чтение коллекций замените на курсорное чтение.
Отслеживайте INFO commandstats после развертываний, чтобы новый шаблон команд не стал для вас неожиданностью.
Настраивайте персистентность с учетом фактического дискового пространства и свободной памяти.
Если один экземпляр Redis действительно насыщен после исправления команд, разделите нагрузку с помощью Redis Cluster, шардирования на стороне клиента, отдельных экземпляров кэша/сессий или более крупного экземпляра с лучшей производительностью одного ядра.

Краткий контрольный список для инцидентов

Во время скачка выполните:

redis-cli INFO cpu
redis-cli INFO commandstats
redis-cli INFO clients
redis-cli INFO memory
redis-cli INFO persistence
redis-cli SLOWLOG GET 20
redis-cli LATENCY LATEST

Затем сопоставьте эти результаты с развертываниями приложений, заданиями cron, изменениями трафика, событиями персистентности и метриками хоста. Высокая загрузка ЦП в Redis обычно исправима, но исправление специфично: удалите дорогую команду, объедините болтливого клиента, остановите переключение соединений, дайте персистентности пространство для работы или разделите нагрузку, когда один экземпляр действительно достиг своего предела.