¿Cómo puedo averiguar qué está martillando mi SQL Server?

Mi CPU SQL Server ha estado en alrededor del 90% durante la mayor parte del día de hoy.

No estoy en condiciones de poder reiniciarlo debido a que está en uso constante.

¿Es posible averiguar lo que dentro de SQL está causando tal sobrecarga de CPU?

He ejecutado SQL Profiler pero está pasando tanto que es difícil saber si algo en particular lo está causando.

He ejecutado sp_who2 pero no estoy seguro de lo que todo significa exactamente y si es posible identificar posible hay problemas aquí.

Para adelantarse a cualquier respuesta de "probablemente solo se esté usando mucho", esto solo ha comenzado hoy desde niveles de actividad perfectamente normales.

Estoy buscando cualquier forma de encontrar lo que está causando dolor de CPU dentro de SQL.

Author: gbn, 2009-06-03
Source

5 answers

Asumo la debida diligencia aquí que confirmó que la CPU es realmente consumida por el proceso SQL (contadores de categoría de proceso perfmon confirmaría esto). Normalmente, para tales casos, toma una muestra de los contadores de rendimiento relevantes y los compara con una línea de base que estableció en condiciones normales de operación de carga. Una vez que resuelva este problema, le recomiendo que establezca una línea de base para futuras comparaciones.

Puede encontrar exactamente dónde está gastando SQL cada CPU ciclo. Pero saber dónde buscar requiere mucho saber cómo y experiencia. Es SQL 2005/2008 o 2000 ? Afortunadamente para 2005 y más nuevos hay un par de soluciones listas para usar. Ya tienes un par de buenos puntos aquí con la respuesta de John Samson. Me gustaría agregar una recomendación para descargar e instalar los informes del Panel de Rendimiento de SQL Server . Algunos de esos informes incluyen las principales consultas por tiempo o por E/S, los archivos de datos más utilizados, etc., y puede obtener rápidamente una sensación de el problema es. La salida es tanto numérica como gráfica, por lo que es más útil para un principiante.

También recomendaría usar el script de Adam Who is Active, aunque es un poco más avanzado.

Y por último, pero no menos importante, le recomiendo que descargue y lea el informe técnico del Equipo de Asesoramiento al Cliente de MS SQL sobre análisis de rendimiento: SQL 2005 Waits and Queues.

Mi recomendación es también mirar E / S. Si agregaste una carga al servidor que elimina el búfer piscina (es decir. necesita tantos datos que desaloja las páginas de datos en caché de la memoria) el resultado sería un aumento significativo en la CPU (suena sorprendente, pero es cierto). El culpable suele ser una nueva consulta que escanea una tabla grande de extremo a extremo.

 26
Author: Remus Rusanu,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-11-15 06:28:25

Esta consulta utiliza DMV para identificar las consultas más costosas por CPU

SELECT TOP 20
    qs.sql_handle,
    qs.execution_count,
    qs.total_worker_time AS Total_CPU,
    total_CPU_inSeconds = --Converted from microseconds
        qs.total_worker_time/1000000,
    average_CPU_inSeconds = --Converted from microseconds
        (qs.total_worker_time/1000000) / qs.execution_count,
    qs.total_elapsed_time,
    total_elapsed_time_inSeconds = --Converted from microseconds
        qs.total_elapsed_time/1000000,
    st.text,
    qp.query_plan
FROM
    sys.dm_exec_query_stats AS qs
CROSS APPLY 
    sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS APPLY
    sys.dm_exec_query_plan (qs.plan_handle) AS qp
ORDER BY 
    qs.total_worker_time DESC

Para una explicación completa ver: Cómo identificar las consultas SQL Server más costosas por CPU

 85
Author: John Sansom,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-01-27 13:07:28

Ejecutar cualquiera de estos unos pocos segundos de diferencia. Detectarás la alta conexión de la CPU. O bien: CPU almacenada en una variable local, WAITFOR DELAY, compare los valores de CPU almacenados y actuales

select * from master..sysprocesses
where status = 'runnable' --comment this out
order by CPU
desc

select * from master..sysprocesses
order by CPU
desc

Puede no ser el más elegante, pero es eficaz y rápido.

 5
Author: gbn,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-06-03 14:29:11

Puede ejecutar el generador de perfiles SQL y filtrar por CPU o Duración para excluir todas las "cosas pequeñas". Entonces debería ser mucho más fácil determinar si tiene un problema como un proc almacenado específico que se está ejecutando mucho más de lo que debería (podría ser un índice faltante o algo así).

Dos advertencias:

  • Si el problema es cantidades masivas de transacciones pequeñas, entonces el filtro que describo anteriormente las excluiría, y te perderías esto.
  • También, si el problema es un trabajo único y masivo (como un trabajo de análisis de 8 horas o una selección mal diseñada que tiene que unir mil millones de filas), entonces es posible que no vea esto en el generador de perfiles hasta que esté completamente hecho, dependiendo de los eventos que esté perfilando (sp:completado vs sp:statementcompleted).

Pero normalmente empiezo con el Monitor de Actividad o sp_who2.

 5
Author: BradC,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-06-03 14:58:52

Para un enfoque GUI, echaría un vistazo a Activity Monitor under Management y ordenaría por CPU.

 3
Author: cmsjr,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-06-03 14:40:33