CPU Utilization = 100%. Это проблема СУБД?⁠⁠

Взято с основного технического канала Postgres DBA

Обычные последствия после получения оповещения мониторинга «CPU Utilization High» — все в панике, лихорадочные поиски причин, аварийная ситуация, конфколлы и т. д. и т. п. Всё, как положено для ИБД.

Однако, если посмотреть на ситуацию чуть подробнее, то выясняется, что всё не так печально, а даже совсем наоборот и причин для паники — никаких.

Что же происходит с СУБД в данный момент ?

А с СУБД, всё хорошо, достаточно посмотреть на метрики мониторинга.

Самое главное: производительность СУБД — не снижается

Уже этой информации достаточно, что бы прекратить панику и не тратить рабочее время на поиски черной кошки в темной комнате.

Почему, производительность СУБД не снижается, ведь CPU в полку?

Причина 1: Количество запросов в секунду — не снижается

Причина 2: Количество транзакций в секунду — не снижается

Т.е. можно сделать простой вывод‑ работоспособность СУБД не уменьшилась, а скорее наоборот — увеличилась и рост утилизации CPU это лишь следствие. Или другими словами — в данной, конкретной ситуации СУБД максимально эффективно использует предоставленные ресурсы.

Данный тезис подтверждается метриками, показывающими количество обрабатываемой СУБД информации за единицу времени (что собственно говоря, с известными сейчас допущениями, и определяет в некотором смысле производительность СУБД).

Выводы

1. Мониторить утилизацию CPU отдельно — не имеет смысла. Мониторить надо производительность СУБД, в первую очередь.

2. Рост утилизации CPU — не инцидент. Снижение производительности СУБД и рост утилизации CPU — инцидент.

3. Высокая утилизация CPU и рост производительности СУБД — показывает эффективное использование предоставленных ресурсов. Низкая утилизация CPU и низкая производительность СУБД в рабочее время — зря потраченные средства.