Мониторинг без плана — это шум. Ищем bottleneck, а не красивые графики

Мониторинг без плана — это шум. Ищем bottleneck, а не красивые графики

Коллеги, давайте разберем план выполнения. Узкое место почти всегда видно не в одном графике, а в связке: рост latency, очередь на I/O, всплеск CPU, блокировки, просадка cache hit. Если смотреть только на один симптом, легко начать лечить не ту систему.

Рабочий порядок простой:
— сначала фиксируем базу: p95/p99 latency, throughput, active sessions, IOPS, wait events;
— потом ищем, что изменилось первым: диск, CPU, память, сеть или конкуренция за блокировки;
— затем проверяем, не маскирует ли проблему кэш: «быстро» в горячем кэше и «медленно» на холодных данных — разные истории.

Схема простая, но дьявол кроется в статистике. Смотрите не на среднее, а на хвосты распределения. Один тяжелый запрос, который живет 200 мс чаще остальных, может не бросаться в глаза в среднем значении, но именно он забивает пул соединений и создает очередь. И да, «после добавления индекса стало хуже» — классика: индекс помогает чтению, но может убить запись и разогреть contention.

Золотое правило: сначала мониторинг, потом индексы. Если метрики не показывают, где именно узко, любая оптимизация превращается в угадайку. Сначала найдите ресурс, который уперся в потолок, потом уже чините запрос, схему или конфигурацию.