Мониторинг без гипотезы — это просто шум. Как искать bottlenecks, а не графики

Мониторинг без гипотезы — это просто шум. Как искать bottlenecks, а не графики

Коллеги, давайте разберем план выполнения. Сначала смотрим не «всё подряд», а цепочку: CPU, память, диск, блокировки, сеть, план запроса. Узкое место обычно не одно, а первое, где очередь начинает расти.

Рабочий минимум такой:
— latency и p95/p99, а не только среднее
— wait events / waits по типу ожидания
— I/O: queue depth, read/write latency, cache hit
— активные сессии, блокировки, deadlock graph
— топ запросов по total time, reads, writes, executions

Если CPU 100%, это не всегда «не хватает ядер». Смотрите, чем заняты процессы: сканами, сортировками, плохими join-ами или вечным перекомпиляционным цирком. Если диск медленный — индексы могут не помочь, а иногда даже ухудшат картину из-за лишних записей. Если же растут ожидания на блокировки, лечить надо не железом, а планом транзакций и длиной hold time.

Золотое правило: сначала мониторинг, потом индексы. Без базовой линии вы не поймёте, стало лучше или просто поменяли один вид боли на другой.

Ищите не симптом, а участок, где система начинает ждать. Именно там и сидит bottleneck.