CPU alta

A CPU do servidor está no limite. Primeiro verifique se é realmente o banco de dados que a está consumindo e depois siga os ramos até a causa raiz: consultas mal planejadas, uma regressão de plano, concorrência excessiva ou um processo que não é do banco.

O banco de dados está realmente consumindo a CPU?

Verifique no sistema operacional qual processo está consumindo CPU. A maior parte da carga está nos processos do banco ou em um processo vizinho (backup, antivírus, outra aplicação)? Isso divide a investigação em duas.

-- 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;

• Sim, os processos do banco estão consumindo a CPU
• Não, um processo vizinho / job de backup está consumindo

Como a carga apareceu?

Se o banco está consumindo a CPU, identifique o padrão: algumas consultas pesadas predominam, o problema começou de repente após uma mudança ou há alta concorrência/contenção de conexões?

• Algumas consultas pesadas estão consumindo a CPU
• Começou de repente; houve um deploy / mudança de parâmetro recente
• Muitas conexões / contenção por concorrência

Encontrar as consultas que mais consomem CPU

Obtenha as principais consultas por consumo total de CPU. Depois decida se cada uma é pesada por chamada (plano ruim) ou barata por chamada, mas chamada com muita frequência.

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;

• Pesada por chamada; plano ruim / full scan
• Barata por chamada, mas chamada com muita frequência

Causa raiz: consultas mal planejadas estão consumindo a CPU

Algumas consultas consomem CPU excessiva por chamada por causa de full scans ou de uma ordem de join ruim. Corrigir seus planos é a solução central.

Causa raiz: frequência de chamadas excessiva

As consultas são baratas individualmente, mas chamadas milhares de vezes por segundo; é daí que vem o custo total de CPU. Geralmente um padrão N+1 ou um hot path sem cache.

Causa raiz: regressão de plano / estatísticas desatualizadas

O sistema estava normal ontem; a CPU disparou após um deploy, mudança de parâmetro ou carga de dados. O otimizador pode ter mudado para um plano pior.

Causa raiz: alta concorrência / contenção de conexões

As consultas individuais são aceitáveis, mas sessões demais rodam ao mesmo tempo; mais sessões ativas que cores de CPU causam troca de contexto e contenção de latch/spin.

Causa raiz: um processo que não é do banco está consumindo CPU

Não é o banco de dados, mas um processo vizinho que está consumindo a CPU: um job de backup/compressão, uma varredura de antivírus, um log shipper ou outra aplicação na mesma máquina.