Обычные последствия после получения оповещения мониторинга «CPU Utilization High» — все в панике, лихорадочные поиски причин, аварийная ситуация, конфколлы и т. д. и т. п. Всё, как положено для ИБД.
Однако, если посмотреть на ситуацию чуть подробнее, то выясняется, что всё не так печально, а даже совсем наоборот и причин для паники — никаких.
Что же происходит с СУБД в данный момент ?
А с СУБД, всё хорошо, достаточно посмотреть на метрики мониторинга.
Самое главное: производительность СУБД — не снижается
Уже этой информации достаточно, что бы прекратить панику и не тратить рабочее время на поиски черной кошки в темной комнате.
Почему, производительность СУБД не снижается, ведь CPU в полку?
Причина 1: Количество запросов в секунду — не снижается
Причина 2: Количество транзакций в секунду — не снижается
Т.е. можно сделать простой вывод‑ работоспособность СУБД не уменьшилась, а скорее наоборот — увеличилась и рост утилизации CPU это лишь следствие. Или другими словами — в данной, конкретной ситуации СУБД максимально эффективно использует предоставленные ресурсы.
Данный тезис подтверждается метриками, показывающими количество обрабатываемой СУБД информации за единицу времени (что собственно говоря, известными сейчас допущениями, и определяет производительность СУБД).
Выводы
Мониторить утилизацию CPU отдельно — не имеет смысла. Мониторить надо производительность СУБД, в первую очередь.
Рост утилизации CPU — не инцидент. Снижение производительности СУБД и рост утилизации CPU — инцидент.
Высокая утилизация CPU и рост производительности СУБД — показывает эффективное использование предоставленных ресурсов. Низкая утилизация CPU и низкая производительность СУБД в рабочее время — зря потраченные средства.
Комментарии (18)
lightman
19.09.2024 06:24Вот как раз на днях был случай. Один из клиентов обращается к нам "у нас БД ложится от высокой нагрузки, идёт вал жалоб от юзеров, что всё висит, это разработанное вами API виновато".
Начинаем разбираться: там на сервере БД загрузка проца около 100%, их технари на стрессе убивают рандомные подключения, хотят ребутать Postgres. Я не какой-то мега-эксперт по постгресу, но первая мысль у меня была такая же "это же абсолютно нормально - ресурс железа используется максимально. Postgres умничка, старается изо всех сил, а вы его хотите лопатой по голове, какое-то немыслимое варварство". Ещё и сервер у них стоит с параметрами железа ниже наших рекомендуемых.
Дальше копаем: на API выставлены стоят высокие лимиты по кол-ву коннектов, итого суммарно со всех API получается более 2000 одновременных соединений. Хотя рекомендуемый лимит коннектов у Postgres кто-то говорит по числу ядер процессора выставлять, кто-то по числу потоков, но в любом случае не больше нескольких десятков. Дали им рекомендацию поставить pgbouncer (не хотят) и сильно уменьшить кол-во одновременных подключений (согласились), больше пока не обращались.
rinace Автор
19.09.2024 06:24Описанная ситуация , ранее была совершенно стандартна и отнимала массу времени и иногда нервов
у нас БД ложится от высокой нагрузки
Сейчас , ситуация несколько иная, если метрика производительности СУБД не уменьшается разговор закончен - "С СУБД аномалий нет, помочь не можем, разбирайтесь с приложением".
там на сервере БД загрузка проца около 100%, их технари на стрессе убивают рандомные подключения, хотят ребутать Postgres.
...
Абсолютно аналогично знакомая ситуация. Совпадения с удивительной точностью .
Юзеры и манагеры - они объективно одинаковы , получается :-)
Kilor
19.09.2024 06:24+2Высокая утилизация CPU - показывает эффективное использование предоставленных ресурсов.
Или она может запросто показывать крайне печальное состояние внутри самой СУБД (пример), или на том же хосте может существовать некий параллельный (иногда даже системный) процесс, "отъедающий CPU".
Поэтому без дополнительных метрик утверждение бессмысленно.rinace Автор
19.09.2024 06:24Изменил/дополнил последний абзац:
Мониторить утилизацию CPU отдельно - не имеет смысла. Мониторить надо производительность СУБД.
Рост утилизации CPU - не инцидент. Снижение производительности СУБД и рост утилизации CPU - инцидент.
Высокая утилизация CPU и рост производительности СУБД - показывает эффективное использование предоставленных ресурсов. Низкая утилизация CPU и низкая производительность СУБД в рабочее время - зря потраченные средства .
печальное состояние внутри самой СУБД (пример)
...
Вот так выглядит загрузка CPU на сервере базы до и после этой операции для примера выше:
Делать выводы - затруднительно. Потому, что нет информации - какая была производительность СУБД до и после. Рискну предположить, что после - производительность выросла. Просто потому, что запрос стал работать быстрее а значить отношение Объем / время - увеличилось.
Но спасибо за наводку для эксперимента - сравнить производительность и утилизацию CPU для очень больших таблиц до и после выполнения ANALYZE. Надо проверить.
Поэтому без дополнительных метрик утверждение бессмысленно.
Уже обсуждали. Замечаний по тому, как бывает в реальной жизни с реальными разрабами - масса. Ну например, для начала:
Много
idle in transaction— скорее всего, у нас перегружена бизнес-логика или pgbouncer. То есть с точки зрения БД вы транзакцию открыли и ушли перекурить.Объяснять им это бесполезно. "У нас так спроектировано". Для завенршения транзакции СУБД ждет подтверждения от внешней системы.
Нет смысла мониторить
Растут
wait— приложение в кого-то «уперлось» на блокировках. Если это уже прошедшая разовая аномалия — повод разобраться в исходной причине.Сама по себе цифра - количество блокировок - ни о чем.
Нет смысла мониторить.
Пики
active(особенно max-значение) демонстрируют, насколько ваше приложение любит ходить в базу «синхронно». То есть вы кинули какой-то сигнал по всем пользователям (например, «опубликована новость») и несколько сотен клиентских приложений одновременно, без всяких задержек, рванули в базу читать…Вообще то сессия в состоянии active либо выполняет запрос либо ожидает освобождения ресурса.
Нет смысла мониторить.
И т.д. и т.п.
В общем смысл в следующем - можно сделать дашбоард мониторинге с десятками и сотнями метрик, графиков и оповещений.
Реальному DBA , в реальной работе это не поможет, а только запутает и не поможет установить реальную причину проблемы.
Я лично не против, может кому то и нравится целый день сидеть и смотреть как меняются графики.
Kilor
19.09.2024 06:24+2сидеть и смотреть как меняются графики
Зачем? График - это инструмент для пост-анализа причин и обнаружения корреляций, которые не прописаны заранее, незачем в них "сидеть".
Объяснять им это бесполезно. ... Реальному DBA , в реальной работе это не поможет
Откуда такая категоричность? Если конкретно вам не повезло с разработчиками, или не хватает возможностей отвечать "за костюмчик" и хочется только "за пуговицы" - это не означает, что так живут все.
rinace Автор
19.09.2024 06:24График - это инструмент для пост-анализа причин и обнаружения корреляций
А можно с этого места поподробнее - как вы устанавливаете наличие и значение корреляции по дискретным значениям метрик по графикам ?
обнаружения корреляций, которые не прописаны заранее
А можно уточнить, что значить "корреляции прописанные заранее" ?
Kilor
19.09.2024 06:24+1Большей частью "глазами", когда это необходимо.
Вот конкретный пример - около 07:14 был аномально резкий резкий рост
block.hit- а почему?.. а потому что из БДIndex Scan'ами выдернули кучу записей:
Статистика чтений записей и блоков данных Дальше мы выявляем, в которой табличке/индексе произошла неприятность:
Индексные чтения записей из таблиц 
Чтения записей из индексов Зная имя индекса, находим подходящие по таймлайну шаблоны планов:
Статистика по шаблонам Видим, что в моменте пришло аномально большое количество "похожих" запросов:
Распределение планов по конкретному шаблону 
Факты по шаблону Берем любой из этих планов, и понимаем, что у нас тут индекса не хватает подходящего:
Анализ конкретного плана Который нам сразу предлагают создать:
Рекомендация по созданию индекса rinace Автор
19.09.2024 06:24Большей частью "глазами", когда это необходимо.
Вот конкретный пример
А можно уточнить - между какими переменными и какое значение коэффициента корреляции в данном примере ?
Kilor
19.09.2024 06:24А зачем мне это значение вычислять? Достаточно глаз и первой картинки, чтобы увидеть, что связь между количеством прочитанных данных и индексно прочитанных записей есть.
То есть я могу, конечно, заранее прописать в явном виде (как это сделано для метрики read.ratio на нижнем графике первой картинки) для каждой пары величин - но зачем?
rinace Автор
19.09.2024 06:24А зачем мне это значение вычислять?
Ок. Принято. Вопросов больше нет.
Спасибо за конструктивный , вежливый диалог.
rinace Автор
19.09.2024 06:24Пользуясь случаем , спасибо за наводку
может запросто показывать крайне печальное состояние внутри самой СУБД
Результаты экспериментов очень интересны и позволяют двигаться дальше . С более эффективными и математически обоснованными результатами экспериментов. Спасибо.
Именно , вот за такие комментарии я и публикую , и буду продолжать публиковать, статьи на Хабре. Мне нужна обратная связь и взгляд со стороны Это классика - "разработчик не тестирует".
Да , раньше с обратной связью и конструктивной дискуссией на Хабре было сильно по другому . Но и сейчас , иногда в потоке флеймофлуда попадаются проблески. А тема , что там в голове у минусаторов это к психологам . Не моя тема.
Так, что , как будет новая статья - не пропустите . Жду обратной связи.
VVitaly
19.09.2024 06:24+3Для севера БД, что утилизация CPU "в потолок", что дисковых метрик "в предел" - однозначно проблемы производительности (времени ответа на запрос) в случае "непредусмотренных" всплесков нагрузки, если конечно же в основном это OLTP нагрузка на БД...
rinace Автор
19.09.2024 06:24однозначно проблемы производительности (времени ответа на запрос)
Какого запроса ? Их сотни и тысячи .
Или вы про метрику время отклика СУБД ?
Есть реальный случай из жизни :
Информационная система деградировала. Ничего не работает, всё висит.
Время отклика СУБД существенно уменьшилось.
michael_v89
19.09.2024 06:24+3Причина 1: Количество запросов в секунду - не снижается
А с чего оно будет снижаться? Если база способна выполнять максимум N запросов в секунду, то она их и будет выполнять. Проблема-то в том, что с отправляющей стороны идет (или может прийти) запросов больше, чем N.
Оно будет снижаться только если процессорное время базы забирает другой процесс.Или другими словами - в данной ситуации СУБД максимально эффективно использует предоставленные ресурсы.
Да, только это очень узкий интервал, когда запросов приходит ровно столько и ровно таких, чтобы загрузить CPU на 99-100%.
Даже если так, то это означает, что у системы нет запаса для временного повышения нагрузки.
А если их приходит больше, значит для кого-то приложение работает медленнее, а возможно и отключается по таймауту, а это значит, что ресурсов системы не хватает.
freiloss
зачастую это означает, что нет запаса по CPU и дальнейшее (обычно вероятное) повышение нагрузки приведёт к уже драматическому снижению ключевых показателей. Вот поэтому собственно народ и дёргается
ildarz
Автор просто живет в параллельной реальности, где ключевые метрики типа времени отклика не просто не являются ключевыми, но и вообще не заслуживают измерения и контроля. Ему не раз объясняли, где и почему он ошибается, в том числе с наглядными, знакомыми любому администратору примерами, но как об стенку горох.
panzerfaust
Оно и IRL так. Если все станки пашут на 100%, все сотрудники головы не поднимают и все площади чем-то забиты, то ты, хозяин, тупо не можешь расширять производство без серьезных вложений. В моменте дело движется, а в перспективе маячит упущенная прибыль. Немного свободного ресурса должно быть.