Как быстро найти bottleneck: не лечить симптомы, а смотреть по цепочке

Как быстро найти bottleneck: не лечить симптомы, а смотреть по цепочке

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

Рабочий чек-лист простой:
— сравните p95/p99 latency с throughput, а не с «средней температурой по больнице»;
— проверьте wait events: какой тип ожидания доминирует и кто его создает;
— найдите top SQL по времени, чтениям, логическим операциям, блокировкам;
— сопоставьте это с ростом очередей на I/O и загрузкой CPU.

Золотое правило: сначала мониторинг, потом индексы. Иначе получится классика — добавили индекс, а bottleneck сидел в сортировке на temp и в 500 мелких запросах в минуту. Схема простая, но дьявол кроется в статистике: один и тот же симптом может быть следствием разного узкого места.

Если коротко: не ищите «главную кнопку ускорения», ищите место, где система перестает успевать за нагрузкой. Посмотрим, что тут с I/O в реальности — и только потом лезем в SQL.