GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Cómo comprobar la utilización de la CPU en SQL Server


Una incidencia relativamente frecuente, es encontrarse una máquina SQL Server con la CPU al 100%, siendo el proceso de SQL Server el que se está llevando prácticamente toda la CPU (esto es lo que se llama un pequeño Problema de Rendimiento ;-). Si la instancia de SQL Server contiene una gran cantidad de bases de datos y de conexiones de usuario, nos resultará de interés poder conocer fácilmente qué procesos (SPID) de SQL Server se están llevando la CPU. En este pequeño artículo, tratamos esta situación e incluimos un pequeño trozo de código de ejemplo para realizar este tipo de diagnóstico.

Pues sí. En ocasiones ocurre. Ya sea por aplicaciones que no estén muy bien optimizadas (en lo relacionado al acceso a la base de datos, indexación, diseño del modelo de datos, etc.), ya sea por consolidar en una única instancia de SQL Server demasiadas bases de datos sin un estudio apropiado previo (encontrándonos con fuertes cargas de trabajo que se solapan), ya sea por cargas excepcionales de trabajo (procesos de cierre de fin de mes), etc.

El caso, es que cuando nos ocurre en nuestras máquinas, en las máquinas que conocemos y con las que trabajamos en el día a día, muchas veces no nos será necesario ni mirar en SQL Server qué ocurre para tenerlo claro. Sin embargo, cuando se trata de máquinas que no conocemos mucho, o incluso en máquinas que conocemos pero que han estado sujetas a recientes cambios de IT o de sus aplicaciones, no surgirá la duda, y nos resultará necesario saber quién se está llevando la CPU de SQL Server, como primer paso para poder diagnosticar la existencia o no de Problemas de Rendimiento en SQL Server.

Podemos consultar la información de los SPIDs en sys.sysprocesses, pero el hecho de que puedan existir aplicaciones que trabajen orientadas a la conexión u orientadas a la desconexión, hace que no resulte tan trivial su interpretación. Recordemos, que una aplicación que trabaja orientada a la conexión, establecerá una conexión a la base de datos, y la mantendrá constantemente, enviando a través de dicha conexión multitud de peticiones, conforme le resulte necesario (ojo, algunas aplicaciones mantienes varias conexiones, cada una de ellas orientada a la conexión). Sin embargo, una aplicación que trabaja orientada a la desconexión, tenderá a mantenerse desconectada de la base de datos, y para cada petición que necesite realizar, creará una conexión a la base de datos para ejecutar dicha petición y seguidamente desconectarse (eso sí, habitualmente, utilizando Pool de Conexiones).

Una forma casera y poco precisa de poder obtener la información del consumo reciente de CPU en SQL Server, consiste en consultar el contenido de sys.sysprocesses varias veces seguidas, separadas por una cantidad de tiempo fija (ej: cada segundo, utilizando WAITFOR DELAY), y con dicha información, intentar obtener el reparto del consumo reciente de la CPU, tanto por SPID como por Base de Datos. Por ejemplo, si tenemos un SPID que aparece en las diferentes consultas realizadas a sys.sysprocesses, podemos estimar su consumo de CPU en este periodo de tiempo, como resultado de restar al valor MAX de CPU el valor MIN de CPU de este SPID.

Insisto en que se trata de un proceso casero y susceptible de errores, pero en alguna ocasión me ha resultado de bastante utilidad (aún con sus deficiencias) para un primer vistazo, por lo que quería aprovechar para compartirlo, para quién le pueda resultar de utilidad.

Por poner un ejemplo de los puntos débiles de este sistema casero, el hecho de utilizar WAITFOR para tomar muestras de sysprocesses cada segundo, puede implicar que muchas conexiones de aplicaciones que trabajan orientadas a la desconexión, no podamos cazarlas, ya que lo lógico es que dichas conexiones tarden menos de un segundo (que ya de por sí, es una barbaridad) en ejecutarse. Aún así, en este caso, si dicha aplicación orientada a la desconexión estuviese generando una gran cantidad de conexiones a SQL Server, deberíamos poder observarlo con este Script, aún a sabiendas de que nos faltarán conexiones, más aún si la máquina está saturada al 100% de CPU (en este caso, todo empezará a ir más lento, aumentando la probabilidad de que cacemos más consultas en cada muestra, al aumentar el tiempo de ejecución de cada consulta por la ausencia de suficientes recursos).

Tiene más puntos débiles, pero bueno, tampoco voy a autoputearme gratuitamente. Digo yo que también habrá que ver lo positivo.

A continuación se incluye el Script comentado, el cual utiliza una tabla temporal en la que almacenar las diferentes ejecuciones de consultas sobre sys.sysprocesses, y finalmente incluye un par de consultas sobre dicha tabla temporal, para obtener información del consumo de CPU por proceso, e información del consumo de CPU por base de datos. La tabla temporal se borra al principio del Script, de tal modo, que si una vez ejecutado el Script necesitamos consultar la información de la tabla temporal, aún estará disponible para nosotros. Al principio del Script tenemos un par de variables, en las que parametrizar el número de muestras que deseamos tomar, y cada cuanto tiempo las deseamos tomar (que sea en múltiplos de un segundo, ya que con fracciones inferiores, el WAITFOR DELAY se interpretará como WAITFOR DELAY 0, es decir, sin separación temporal entre cada muestra). Este Script permite comprobar el consumo de CPU en SQL Server 2008, SQL Server 2005 y SQL Server 2000.

Descargar Script para Comprobar Consumo CPU SQL Server (Comprobar_consumo_CPU_SQLServer.sql.txt)

 


[Fecha del Artículo (UTC): 01/02/2011]
[Autor: GuilleSQL]


Comentarios

MiguelParra - 13/05/2011 (UTC)
Me ha venido perfecto. Gran Trabajo y Muchas Gracias por compartirlo.


rboecillo - 02/12/2012 (UTC)
Hola, muchas gracias por tu artículo, he lanzado ese script
y el resultado es

master 96094
KAV 376
BIB_AYTO 32

tengo el consumo d ela CPU del servidor al 100% por culpa del SQL es un 2005 32 bits como ves la master se lleva la palma, KAV es una bbdd del antivirus corporativo y BIB_AYTO es un gestor documental.

alguna idea de por donde seguir? seguramente que si reinicio el servidor el problema se solucione pero me gustaría saber tu opinión al respecto.

muchas gracias.


GuilleSQL - 02/12/2012 (UTC)

Hola,

Ahora que tienes localizada la BBDD, puedes lanzar el comando sp_who2 para ver qué procesos están corriendo sobre la BBDD master. Si te fijas en la salida de este comando y ves el consumo de CPU, puedes lanzarlo varias veces, de tal modo, que puedas ver entre las diferentes ejecuciones de sp_who2 cuál es el proceso que se está llevando la CPU.

Saludos,
Guille


pplu123 - 25/03/2015 (UTC)
Hola

Muy buen artículo!!!

2 ó 3 preguntas.

-¿Cómo lo ejecutas para que salgan los valores de varias BBDD?? porque yo sólo sé ejecutarlo sobre una BBDD.

-¿Qué valores son altos, bajos, medios, etc? ¿De qué depende?

-Una última pregunta. En verdad necesito saber nº de inserciones que se están haciendo en BBDD, y me pasa lo mismo, querría saber cuáles son valores altos, bajos, medios?

Muchas Gracias
Saludos



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas