Bojan Petrovic
Utilization of processor time alert details page

Herramienta de supervisión de SQL Server para el rendimiento de la CPU

May 24, 2019 by

Saturación del CPU ralentiza el servidor

Este artículo es otro capítulo de la serie sobre las herramientas de supervisión de SQL Server y de los problemas más comunes sobre el rendimiento. Antes de empezar leer este artículo, les recomiendo leer antes, los dos artículos anteriores sobre herramientas de monitoreo para el I/O del disco y del rendimiento de la memoria:

De todos modos, si solo estás interesado en la saturación del CPU, está bien. Este artículo también se puede leer de forma independiente. Solo que aconsejo leer toda la secuela ya que todo está conectado de alguna manera. Para empezar, siempre me gusta mencionar algunos síntomas que indican un problema en la condición del CPU:

  • Un uso repentino alto del CPU – se puede ver un uso alto del CPU en el Administrador de tareas de Windows. Esto es obvio cuando ve que la CPU está conectada, es una buena señal de que algo está sucediendo
  • Aumento del I/O – los problemas de la CPU pueden manifestarse a partir de los problemas de I/O y de memoria. Por lo tanto, el I/O también debe verificarse al solucionar problemas de la CPU
  • Compilaciones altas – muchas recopilaciones pueden agregar algunos ciclos al CPU
  • Consultas complicadas – incluso más que la anterior

Herramientas para monitorizar el rendimiento

Vistas de gestión dinámicas

En primer lugar, tenemos un excelente DMV llamado sys.dm_exec_query_stats que nos devuelve las estadísticas de rendimiento agregadas para los planes de consulta del caché en el SQL Server. Estas DMV se puede utilizar de muchas maneras. Como por ejemplo, se puede usar tanto para encontrar un elevado número de recopilaciones como para consultas complicadas.

Entonces, vamos a ver distintas formas en que esta estadística de consulta se usa como una herramienta de monitoreo de SQL Server. Hay que pegar el siguiente código y ejecútalo:

Ahora puede ver una selección de las estadísticas de la consulta donde la generación de planes es mucho mayor que una. Pues eso es solo un indicador de que una consulta ha hecho más de una recopilación. Si se hace más de uno, es muy factible que continúe haciéndolo. He aquí mi resultado:

Results of a query used as SQL Server monitoring tool for finding high recompiles

En un entorno de producción, lo más probable es que se obtenga un mayor conjunto de datos.

Otra manera de usar las estadísticas de consulta se muestra en el siguiente código. Pero esta vez, estamos encontrando las 10 consultas más complicadas. Tiene que pegar el siguiente código en el editor de consultas y ejecutarlo.

Siéntase libre de editar la parte de TOP e ingrese el número deseado de consultas que desee que se devuelvan:

Results of a query used as SQL Server monitoring tool for finding expensive queries

Se dará cuenta que ambas consultas son idénticas, a excepción de lo que estamos seleccionando y en la segunda consulta ordenamos por tiempo total de trabajo, lo que principalmente devolverá información sobre las consultas de la parte de TOP N clasificadas por tiempo de procesador.

Monitor de rendimiento

En el lado del Monitor de rendimiento, obtenemos algunas de las herramientas de monitoreo del SQL Server, contadores AKA que se pueden utilizar para poder solucionar los problemas de rendimiento de la CPU. Los contadores a continuación son simples y fáciles de usar:

  • Procesador % Tiempo de procesador == < 80%
  • Procesador % de tiempo de usuario == < 80%
  • Procesador % de tiempo privilegiado == < 30%

Comprender el tiempo del procesador no es nada difícil. Por lo general, este valor debe ser inferior al 80 por ciento. Esta misma regla se aplica para el tiempo del usuario y, por último, el tiempo privilegiado debe ser inferior al 30 por ciento. Si alguno de estos está más arriba, es una buena señal de que estamos estresando la CPU. Tengamos en cuenta que, al solucionar los problemas del CPU con cualquier herramienta de monitoreo de SQL Server, siempre tiene que tener en cuenta los siguientes factores externos y no solo los del CPU que está causando ciclos adicionales.

Si nos vamos a ver el Monitor de rendimiento, podemos crear de forma rápida otro conjunto de recopiladores de datos y poder agregar los contadores de rendimiento anteriores. Yo lo mantuve funcionando durante unos 10 minutos solo para poder crear registros de datos de contadores que incluimos anteriormente. Pero esta vez, no ejecuté la herramienta de estrés en segundo plano porque claramente generaría calor en mi equipo y ese no es el objetivo. El objetivo aquí es poder identificar si la CPU está bajo la presión en circunstancias normales. A continuación, están mis resultados:

SQL Server monitoring tool for CPU utilization in Windows

Al observar este informe, podemos darnos cuenta que el tiempo privilegiado es bastante bueno, lo mismo pasa con el tiempo del procesador y del usuario. Todos ellos están en buena forma. Pero, nuevamente, en mi equipo. Los resultados en este ejemplo: El servidor de producción puede ser radicalmente diferente. Hay que estar atento a estos contadores que no excedan los números especificados anteriormente.

En vez de escribir otro artículo en serie acerca las herramientas de monitoreo de SQL Server, quiero acaparar brevemente la concurrencia que mencioné en el primer artículo en la lista de problemas de rendimiento más comunes. La concurrencia es bastante fácil de solucionar. Esto llega a ser lo contrario a lo que escribí en el artículo inicial, cuando dije que es una tuerca difícil de romper. Las dos afirmaciones son algo ciertas. Todo esto depende de cómo se manifieste la concurrencia.

Algunos buenos síntomas de concurrencia serán:

  • Rendimiento lento
  • Bloqueo de eventos
  • La utilización del CPU/ memoria/ I/O es normal, pero…

El último punto es complicado porque la CPU, la memoria y el I/O pueden estar en orden, pero las personas aún se pueden molestar por los de los problemas en el rendimiento, lo que es un buen indicador de que es muy factible que nosotros tengamos un problema con la concurrencia. A parte de eso, este problema probablemente proviene del cierre o bloqueo.

Tenemos dos DVM para descubrir los bloqueos:

Del lado del Monitor de rendimiento, también tenemos dos contadores:

  • SQLServer:Locks\Lock Waits/sec == 0
  • SQLServer:Locks\Lock Wait Time (ms) == 0

Estos dos combinados nos van a dar una buena señal de que si hay algún bloqueo y qué tan grave es este. Estoy muy seguro de que no tengo ningún bloqueo en mi máquina local, por lo que ni siquiera intentare ir al Monitor de rendimiento, aunque el objetivo es que esos contadores se pueden usar como una herramienta de supervisión de SQL Server para poder solucionar los problemas de bloqueo.

Alternativas

Como te mencioné anteriormente, prefiero usar la herramienta de monitoreo de SQL Server llamada ApexSQL Monitor. Esta herramienta ya está precargada con líneas de base recomendadas para la utilización del tiempo del procesador. Una vez que ya esté instalado, no solo podrá supervisar el rendimiento de SQL Server, sino que también varias métricas del sistema, entre las que se encuentra el tiempo de procesador. Si recuerdas desde el comienzo, el tiempo del procesador siempre debe ser inferior al 80 por ciento. Si este excede ese valor, la aplicación va a generar una alerta como la que se muestra a continuación en la siguiente figura:

Alerts page of ApexSQL Monitor application

Puedes hacer clic en la alerta y poder desglosar desde los detalles de la alerta hasta las esperas de consulta:

Utilization of processor time alert details page

La información está de una forma detallada sobre las métricas del sistema que se pueden recuperar haciendo clic en el enlace Detalles en el panel Sistema:

System pane of an instance on the home page of the application

Esta acción te llevará a otra página y así es como se va a ver:

Monitoring of various system metrics page

Si por ejemplo haces clic en: Utilizar el enlace del tiempo del procesador [%], aparecerá una ventana emergente de AKA Metric helper:

Utilization of processor time metric helper

Los ayudantes de métricas incorporan información completa sobre todas las métricas, las soluciones recomendadas y el punto de partida para la investigación adicional.

Una estrategia para la solución de los problemas

Un último punto que quiero mencionar es que la estrategia de solución de problemas, siempre resulta útil para poder resolver problemas en cualquier nivel, en especial los problemas de rendimiento para tener una estrategia en su lugar. De esa manera, cuando ocurra un momento crítico, se podrá abordar el problema de una forma correcta. Aquí tenemos una lista de lo que debe hacer y en el orden que debe ser:

  1. Defina el problema – se puede poner difícil ya que puede ser tan general como “todo está lento” o “el sistema no responde”. En el mejor caso es cuando el problema es específico y podemos tener algo como “Es un problema de bloqueo en esta tabla”. De todas maneras, esto debería ser el punto de partida. Yo no haría nada sin antes describir el problema lo más detallado posible
  2. Analice si es interno o externo – este es un paso muy importante porque puede ayudarnos a poder solucionar casi la mitad del problema. Especialmente si hay otras cosas ejecutándose en el SQL Server, eso puede abrir una olla de grillos completamente nueva. Así que, si es interna, estás a mitad del camino. Si no es así, bueno, entonces ya es otra historia, pero de cualquier manera siempre pasaría por este paso
  3. Determine si está vigente o está en curso – si sabemos que es un problema interno (el problema es el servidor SQL), tenemos averiguar si este está vigente o en curso. Vigente significa que acaba de suceder, con esto estamos seguros de que esta es la primera vez que se produce un problema. Si está en curso, quiere decir que tal vez haya pasado una semana sin siquiera saber que este problema está allí. En este caso, los registros nos pueden ayudar. Así mismo, digamos que es la primera vez que lo vemos, pero simplemente no sabemos si ha estado en curso o no. Entonces puedes configurar un evento extendido y/o un Monitor de rendimiento o cualquier otra herramienta de monitoreo de SQL Server de tu preferencia, poder ejecutar por un día o dos para descubrir si alguno es un problema repetido o es un problema que solo paso una vez.
  4. Identifique y resuelva – este punto es obvio y no necesita ninguna explicación. Con un poco de suerte y siguiendo los tres pasos anteriores, llegarás a solucionarlo rápidamente

Quiero finalizar con este tercer artículo sobre herramientas de monitoreo de SQL Server. Deseando que esta serie de artículos te hayan sido informativos y de gran ayuda. Le agradezco el que los haya leído.

Tabla de contenido

Las herramientas de supervisión de SQL Server para el rendimiento de e/S de disco
Las herramientas de monitorización de SQL Server para el rendimiento de la memoria
Herramienta de supervisión de SQL Server para el rendimiento de la CPU

Bojan Petrovic

Bojan Petrovic

Experienced QA Engineer with a demonstrated history of working in the computer software industry.
Skilled in network technologies, technical support, Windows SQL Server, etc.
Strong information technology professional with an AP graduate in IT Technology focused on Networks and electronic technology from the Copenhagen School of Design and Technology.
Bojan Petrovic
Monitoreo, Performance

Acerca de Bojan Petrovic

Experienced QA Engineer with a demonstrated history of working in the computer software industry. Skilled in network technologies, technical support, Windows SQL Server, etc. Strong information technology professional with an AP graduate in IT Technology focused on Networks and electronic technology from the Copenhagen School of Design and Technology.

407 Views