Как использовать INFO COMMANDSTATS для статистики команд

Команда `INFO COMMANDSTATS` в Redis предоставляет детальную статистику по выполнению каждой команды, что позволяет анализировать нагрузку, выявлять узкие места и оптимизировать производительность. Эта информация особенно ценна для администраторов баз данных и DevOps-инженеров, отвечающих за масштабируемость и стабильность систем. Данные доступны в реальном времени и не требуют дополнительных инструментов мониторинга.

Что такое INFO COMMANDSTATS и зачем он нужен

Redis — высокопроизводительная in-memory база данных, используемая для кэширования, хранения сессий, очередей и других задач. Одной из его ключевых особенностей является возможность получения подробной внутренней статистики через команду `INFO`. Раздел `COMMANDSTATS` — один из подразделов этой команды, который фокусируется исключительно на метриках использования команд.
Данный раздел отображает, сколько раз была вызвана каждая команда, сколько суммарного времени она заняла и среднее время выполнения. Эти данные собираются динамически с момента запуска сервера или последнего сброса статистики. Это делает `COMMANDSTATS` мощным инструментом профилирования производительности.
Анализ статистики позволяет понять, какие команды создают наибольшую нагрузку на CPU, какие используются слишком часто, а какие могут быть заменены более эффективными аналогами. Например, множественные вызовы `GET` могут сигнализировать о необходимости оптимизации кэширования, а частые `KEYS` — о проблемах с архитектурой ключей.

Как включить и использовать INFO COMMANDSTATS

Команда `INFO COMMANDSTATS` доступна по умолчанию в Redis начиная с версии 2.6.0, но детализация появилась только в 3.2.0. Никаких дополнительных настроек для её активации не требуется — достаточно иметь доступ к Redis CLI или соответствующему API-интерфейсу.
Для получения данных выполните в терминале:

1. Подключитесь к Redis: redis-cli -h [host] -p [port]
2. Выполните: INFO COMMANDSTATS
3. Или получите весь INFO и отфильтруйте: INFO | grep -A 50 command_stats

Пример вывода:

# Commandstats
cmdstat_get:calls=12000,usec=24000,usec_per_call=2.00
cmdstat_set:calls=8000,usec=16000,usec_per_call=2.00
cmdstat_keys:calls=50,usec=150000,usec_per_call=3000.00

Каждая строка содержит имя команды и три метрики: количество вызовов, общее время выполнения в микросекундах и среднее время на один вызов. Данные можно запрашивать периодически для трендового анализа.

Шаги для регулярного сбора данных

• Настройте cron-задачу, которая раз в минуту выполняет INFO COMMANDSTATS и сохраняет результат в файл или временную БД.
• Используйте скрипт на Python, Bash или Go для автоматического парсинга и отправки метрик в Prometheus, Grafana или другую систему мониторинга.
• Очистите статистику перед тестированием с помощью CONFIG RESETSTAT, чтобы получить «чистые» данные.

Структура вывода COMMANDSTATS: разбор полей

Формат каждой строки в `INFO COMMANDSTATS` строго структурирован:
cmdstat_{команда}:calls={число},usec={микросек},usec_per_call={дробь}
Разберём значение каждого поля:

• calls — общее количество вызовов команды с момента запуска или сброса статистики. Позволяет оценить популярность команды.
• usec — суммарное время выполнения всех вызовов в микросекундах. Отражает общую нагрузку на CPU.
• usec_per_call — среднее время одного вызова. Критично для выявления медленных операций.

Например, если `usec_per_call` для `HGETALL` превышает 1000 микросекунд (1 мс), это может указывать на работу с большими хэшами, что нежелательно в продакшене.

Как интерпретировать аномалии

Обратите внимание: некоторые команды, такие как `PING`, `SELECT`, `AUTH`, обычно имеют минимальное время выполнения, но высокий `calls`. Это нормально. А вот `SLOWLOG` или `FLUSHDB` в списке — повод проверить безопасность и политики доступа.

Практический анализ: сценарии использования

Рассмотрим реальные кейсы, где `INFO COMMANDSTATS` помог решить проблему.

Сценарий 1: Высокая задержка в API

Команда разработчиков заметила рост latency в API. Через `INFO COMMANDSTATS` было выявлено:

cmdstat_hgetall:calls=5000,usec=1200000,usec_per_call=240.00

Анализ показал, что `HGETALL` вызывается для получения всех полей профиля пользователя, включая редко используемые. Решение: переход на `HGET` с конкретными полями и кэширование на стороне приложения.

Сценарий 2: Периодические зависания Redis

В логах наблюдались моменты блокировки. В `COMMANDSTATS` обнаружена строка:

cmdstat_keys:calls=12,usec=3600000,usec_per_call=300000.00

Команда `KEYS *` занимала до 300 мс на вызов. Это недопустимо для in-memory БД. Замена на `SCAN` с итератором устранила проблему.

Сценарий 3: Оптимизация Lua-скриптов

Использовались скрипты для атомарных операций. `COMMANDSTATS` показал:

cmdstat_eval:calls=200,usec=400000,usec_per_call=2000.00

После рефакторинга (удаление лишних циклов, использование `redis.call` вместо `pcall`) среднее время снизилось до 600 мкс.

Интеграция с системами мониторинга

Для постоянного контроля `COMMANDSTATS` следует интегрировать в систему мониторинга. Ниже — пример реализации.

Шаги для интеграции с Prometheus

1. Установите экспортер, например, redis_exporter, который поддерживает парсинг `INFO COMMANDSTATS`.
2. Настройте scrape в Prometheus: добавьте job с адресом экспортера.
3. Создайте дашборд в Grafana: отобразите top-10 команд по calls и usec_per_call.
4. Настройте алерты: например, при росте `usec_per_call` для `ZUNIONSTORE` более чем на 50% за 5 минут.

Альтернативные решения

• Telegraf + InfluxDB: используйте input plugin для Redis, который автоматически собирает `INFO`-данные.
• Custom скрипт на Python: с библиотекой redis-py, парсит вывод и отправляет в любой бэкенд.
• OpenTelemetry: для распределённого трейсинга — можно связать вызовы команд с HTTP-запросами.

Распространённые ошибки и как их избежать

Несмотря на простоту, при работе с `INFO COMMANDSTATS` часто допускают типичные ошибки.

Ошибка 1: Анализ абсолютных значений без учёта времени

Разработчик видит, что `calls=1000000` для `GET`, и делает вывод о проблеме. Но если сервер работает неделю, это всего ~2 вызова в секунду — норма. Всегда рассчитывайте скорость: calls / uptime_in_seconds.

Ошибка 2: Игнорирование контекста окружения

Высокие значения `usec_per_call` на тестовом сервере с HDD не релевантны для продакшена на NVMe. Тестируйте в условиях, максимально приближённых к боевым.

Ошибка 3: Сброс статистики в процессе мониторинга

Выполнение `CONFIG RESETSTAT` обнуляет все счётчики, включая `COMMANDSTATS`. Если вы этого не ожидали — теряете историю. Перед сбросом делайте экспорт данных.

Ошибка 4: Отсутствие фильтрации редких, но дорогих команд

Команда `BGREWRITEAOF` может вызываться раз в день, но потреблять много ресурсов. Её легко пропустить при сортировке по `calls`. Фильтруйте также по `usec` и `usec_per_call`.

Экспертное мнение

Анализ команд должен быть частью регулярного аудита производительности. Устанавливайте пороговые значения для критических метрик: например, ни одна команда не должна превышать 5 мс в среднем времени выполнения. Исключения — фоновые операции вроде `SAVE` или `BGSAVE`.
Регулярно проводите «профилировочные недели»: отключите кэширование на клиенте, соберите данные за 24 часа и проанализируйте топ-10 самых затратных команд. Часто находятся скрытые проблемы: например, использование `SMEMBERS` вместо `SSCAN` в цикле.
Интегрируйте `COMMANDSTATS` в CI/CD: при деплое нового кода запускайте нагрузочный тест и сравнивайте статистику до и после. Если количество вызовов `DEL` выросло в 10 раз — возможно, изменилась логика очистки кэша, что требует проверки.
Для крупных систем рекомендуется вести историю статистики хотя бы за 30 дней. Это позволяет выявлять сезонные пики, например, рост `INCR` в начале месяца из-за бизнес-логики.

Вопросы и ответы

Заключение

Команда `INFO COMMANDSTATS` — это мощный, но недооценённый инструмент диагностики производительности Redis. Она предоставляет точечные данные о том, какие команды и сколько ресурсов потребляют, позволяя принимать обоснованные решения по оптимизации.

• Используйте `INFO COMMANDSTATS` для анализа нагрузки на Redis в реальном времени.
• Следите за метриками calls, usec и usec_per_call — они дают полную картину.
• Интегрируйте данные в системы мониторинга для долгосрочного анализа.
• Избегайте типичных ошибок: анализируйте в контексте времени и окружения.
• Внедряйте профилирование как регулярную практику в разработке и эксплуатации.