DBAtlas · Atlas de operações de banco de dados

CPU alta

Sintoma

CPU do servidor acima de 90%; o sistema inteiro está lento e o load average está alto.

1. Confirme que é o banco que está consumindo a CPU

Use top/mpstat no nível do SO para confirmar que o processo que consome CPU é realmente o banco. Às vezes o consumidor é um processo vizinho ou um backup/antivírus. Se o iowait estiver alto, o problema é o disco, não a CPU.

2. Encontre as consultas que mais usam CPU

Levante as principais consultas ordenadas por tempo de CPU. Geralmente poucas consultas (plano ruim, full scan, índice ausente) queimam a CPU.

Oracle

SELECT sql_id, cpu_time/1e6 cpu_sec, executions, sql_text FROM v$sql ORDER BY cpu_time DESC FETCH FIRST 10 ROWS ONLY;

PostgreSQL

SELECT query, calls, total_exec_time, mean_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;

MySQL

SELECT digest_text, count_star, sum_timer_wait/1e12 sec FROM performance_schema.events_statements_summary_by_digest ORDER BY sum_timer_wait DESC LIMIT 10;

SQL Server

SELECT TOP 10 total_worker_time/execution_count avg_cpu, execution_count, SUBSTRING(t.text,1,200) FROM sys.dm_exec_query_stats q CROSS APPLY sys.dm_exec_sql_text(q.sql_handle) t ORDER BY total_worker_time DESC;

3. Verifique se há problema de plano/índice

Obtenha o plano da consulta problemática. Full table scans, explosões de nested loop, spills de hash join ou planos ruins causados por parameter sniffing/estatísticas desatualizadas queimam CPU. Crie um índice ou colete estatísticas.

4. Alivie imediatamente

Mate a consulta descontrolada e, se necessário, limite-a com Resource Manager/Resource Governor. Para uma carga que começou de repente, revise o último deploy/mudança de parâmetro.

5. Corrija de forma definitiva

Corrija a consulta/índice, garanta a estabilidade do plano e agende o job de coleta de estatísticas. Se a CPU estiver constantemente em 100%, pode ser preciso escalar (adicionar CPU, distribuir leituras para réplicas de leitura).

Abrir no DBAtlas →