DBAtlas · Atlas de operaciones de bases de datos

CPU alta

La CPU del servidor está al máximo. Verifique primero que es realmente la base de datos la que la consume y luego siga las ramas hasta la causa raíz: consultas mal planificadas, una regresión de plan, concurrencia excesiva o un proceso ajeno a la BD.

¿Es realmente la base de datos la que consume la CPU?

Compruebe en el lado del sistema operativo qué proceso está consumiendo CPU. ¿La mayor parte de la carga está en los procesos de la BD o en un proceso vecino (backup, antivirus, otra aplicación)? Esto divide la investigación en dos.

-- 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;
  • Sí, los procesos de la BD consumen la CPU
  • No, la consume un proceso vecino / un job de backup

¿Cómo apareció la carga?

Si la BD consume la CPU, identifique el patrón: ¿dominan unas pocas consultas pesadas, empezó el problema de repente tras un cambio o hay alta concurrencia/contención de conexiones?

  • Unas pocas consultas pesadas consumen la CPU
  • Empezó de repente; hubo un despliegue / cambio de parámetros reciente
  • Muchas conexiones / contención por concurrencia

Encontrar las consultas que más CPU consumen

Extraiga las consultas principales por consumo total de CPU. Luego decida si cada una es pesada por llamada (mal plan) o barata por llamada pero invocada con mucha frecuencia.

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 llamada; mal plan / full scan
  • Barata por llamada pero invocada con mucha frecuencia

Causa raíz: consultas mal planificadas consumen la CPU

Unas pocas consultas consumen CPU excesiva por llamada por full scans o un mal orden de join. Corregir sus planes es la solución principal.

Causa raíz: frecuencia de llamadas excesiva

Las consultas son baratas individualmente pero se invocan miles de veces por segundo; de ahí sale el costo total de CPU. Normalmente un patrón N+1 o una ruta caliente sin caché.

Causa raíz: regresión de plan / estadísticas obsoletas

Ayer el sistema iba normal; la CPU se disparó tras un despliegue, un cambio de parámetros o una carga de datos. El optimizador puede haber cambiado a un plan peor.

Causa raíz: alta concurrencia / contención de conexiones

Las consultas individuales son aceptables, pero se ejecutan demasiadas sesiones a la vez; más sesiones activas que núcleos de CPU provocan cambios de contexto y contención de latch/spin.

Causa raíz: un proceso ajeno a la BD consume CPU

No es la base de datos sino un proceso vecino el que consume la CPU: un job de backup/compresión, un escaneo de antivirus, un enviador de logs u otra aplicación en la misma máquina.

Abrir en DBAtlas →