Высокая загрузка CPU

CPU сервера загружен до предела. Сначала убедитесь, что его действительно потребляет база данных, затем пройдите по веткам к первопричине: запросы с плохими планами, регрессия плана, избыточная конкурентность или процесс вне БД.

Действительно ли CPU потребляет база данных?

Проверьте на стороне операционной системы, какой процесс сжигает CPU. Основная нагрузка в процессах БД или в соседнем процессе (бэкап, антивирус, другое приложение)? Это делит расследование на две ветки.

-- OS side: top -o %CPU  (or: top -c)
-- DB-side verification:
SELECT ROUND(value,1) AS host_cpu_util_pct FROM v$sysmetric WHERE metric_name='Host CPU Utilization (%)' AND rownum=1;

• Да, CPU потребляют процессы БД
• Нет, его потребляет соседний процесс / задание бэкапа

Как проявилась нагрузка?

Если CPU потребляет БД, определите шаблон: преобладают несколько тяжёлых запросов, проблема началась внезапно после изменения или есть высокая конкурентность/конкуренция за соединения?

• CPU сжигают несколько тяжёлых запросов
• Началось внезапно; недавно был деплой / изменение параметров
• Много соединений / конкуренция параллельных запросов

Найдите запросы, потребляющие больше всего CPU

Получите топ запросов по суммарному потреблению CPU. Затем определите, тяжёл ли каждый за один вызов (плохой план) или дёшев за вызов, но вызывается очень часто.

SELECT sql_id, executions, ROUND(cpu_time/1e6,1) AS cpu_sec, ROUND(cpu_time/GREATEST(executions,1)/1000,2) AS cpu_ms_per_exec, sql_text
FROM v$sql ORDER BY cpu_time DESC FETCH FIRST 10 ROWS ONLY;

• Тяжёлый за вызов; плохой план / полное сканирование
• Дешёвый за вызов, но вызывается очень часто

Первопричина: CPU сжигают запросы с плохими планами

Несколько запросов потребляют избыточный CPU за вызов из-за полных сканирований или плохого порядка соединений. Исправление их планов — основное решение.

Первопричина: избыточная частота вызовов

По отдельности запросы дешёвые, но вызываются тысячи раз в секунду; отсюда и суммарная стоимость CPU. Обычно это шаблон N+1 или некэшируемый горячий путь.

Первопричина: регрессия плана / устаревшая статистика

Вчера система работала нормально; CPU подскочил после деплоя, изменения параметров или загрузки данных. Оптимизатор мог переключиться на худший план.

Первопричина: высокая конкурентность / конкуренция за соединения

Отдельные запросы приемлемы, но одновременно работает слишком много сессий; активных сессий больше, чем ядер CPU, что вызывает переключения контекста и конкуренцию latch/spin.

Первопричина: CPU потребляет процесс вне БД

CPU потребляет не база данных, а соседний процесс: задание бэкапа/сжатия, антивирусная проверка, отправщик журналов или другое приложение на той же машине.