Мониторинг производительности без паники: как быстро найти узкое место

Мониторинг производительности без паники: как быстро найти узкое место

Коллеги, давайте разберем план выполнения: узкое место редко живет там, куда первым делом смотрит команда. CPU, память и диск надо смотреть вместе, а не по очереди. Если растет latency, но CPU пустой — ищите ожидания, блокировки и I/O, а не «еще один индекс на всякий случай».

Схема простая, но дьявол кроется в статистике. Сначала смотрим базовую линию: p95/p99, QPS, активные сессии, очередь диска, buffer/cache hit ratio, waits. Потом сравниваем с нормой для этого же сценария: отчет, батч, OLTP, фоновые джобы. Один высокий счетчик ничего не доказывает, важен набор симптомов.

Дальше быстрое разветвление:
— CPU высокий: тяжелые планы, лишние сканы, плохая селективность.
— I/O высокий: большие чтения, плохой кэш, холодные страницы, журнал.
— Locks/waits: конкуренция за строки, таблицы, транзакции.
— Memory pressure: вытеснение кэша, spill на диск, сортировки и hash join.

Золотое правило: сначала мониторинг, потом индексы. Иначе можно «ускорить» запрос ценой роста блокировок, размера индекса и нагрузки на запись. Посмотрим, что тут с I/O в реальности: часто узкое место не в SELECT, а в соседнем UPDATE, который держит ресурс и душит весь поток.

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