CPU alta

Síntoma

CPU del servidor al 90%+; todo el sistema está lento y el load average es alto.

1. Verifique que la BD es realmente la que consume la CPU

Use top/mpstat a nivel de SO para verificar que el proceso que consume CPU es realmente la BD. A veces el consumidor es un proceso vecino o un backup/antivirus. Si el iowait es alto, el problema es el disco, no la CPU.

2. Encuentre las consultas que más CPU usan

Extraiga las consultas principales ordenadas por tiempo de CPU. Normalmente unas pocas consultas (mal plan, full scan, índice faltante) consumen la 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. Compruebe si hay un problema de plan / índice

Obtenga el plan de la consulta problemática. Los full table scans, la explosión de nested loops, los derrames (spills) de hash join o los malos planes causados por parameter sniffing/estadísticas obsoletas consumen CPU. Agregue un índice o recopile estadísticas.

4. Alivie de inmediato

Termine la consulta descontrolada y, si es necesario, limítela con Resource Manager/Resource Governor. Ante una carga que empezó de repente, revise el último despliegue/cambio de parámetros.

5. Corrija de forma permanente

Corrija la consulta/índice, asegure la estabilidad del plan y programe el job de recopilación de estadísticas. Si la CPU está constantemente al 100%, puede ser necesario escalar (agregar CPU, distribuir lecturas en réplicas de lectura).