En esta publicación, analizaré una metodología general para solucionar problemas de rendimiento de la CPU. Me gusta aplicar metodologías de forma predeterminada y también me gusta desarrollar eficiencias en la forma en que resuelvo problemas en función de experiencias pasadas. Sin un marco general, se vuelve demasiado fácil pasar por alto la verdadera causa raíz en medio de una crisis.
Los pasos que describiré en esta publicación son los siguientes:
Este artículo cubrirá cada uno de estos pasos. Asumiré que es posible que no esté utilizando una herramienta de monitoreo de terceros. Sin embargo, si es así, el marco aquí todavía se aplica, pero sus fuentes de datos y herramientas a su disposición variarán de lo que describo.
Definir el problema
Primero tenemos que analizar el problema. Cuando alguien se le acerca y le dice que está viendo un problema de rendimiento de la CPU, esto podría significar muchas cosas diferentes. Entonces, la primera tarea es comprender cuál es la naturaleza del problema de rendimiento de la CPU actualmente.
Algunas categorías comunes incluyen:
- La disponibilidad se ve afectada debido a las "CPU vinculadas". Por ejemplo, todos los planificadores se ejecutan al 100 % en todos los ámbitos y el rendimiento se detiene o se reduce significativamente.
- Degradación del rendimiento debido a un uso de la CPU "superior a lo normal". Por lo tanto, no estamos vinculados, pero sus CPU se ejecutan a un porcentaje más alto de lo normal y, presumiblemente, está afectando el rendimiento.
- Otra categoría común de problema de rendimiento de la CPU es el escenario de "ganadores y perdedores" en el que las cargas de trabajo compiten entre sí. Tal vez tenga una carga de trabajo de OLTP que experimente un rendimiento reducido debido a una consulta de informe de ejecución paralela.
- Otro problema podría ser encontrarse con un punto de inflexión, donde la capacidad general y las limitaciones de escalabilidad de su sistema se ven afectadas en un punto determinado.
Menciono estas categorías generales como punto de partida, pero sé que a menudo puede haber fuertes dependencias entre estos problemas y una categorización puede mezclarse con la otra. Dicho esto, el primer paso es definir los síntomas y problemas lo más claramente posible.
Validar las condiciones actuales
Ya sea que el problema haya ocurrido en el pasado o esté ocurriendo en este momento, es importante obtener la mayor cantidad posible de información de antecedentes sobre el sistema, la carga de trabajo y las configuraciones. Si está utilizando líneas de base y libros de ejecución, lo ideal es que ya esté rastreando gran parte de esta información. Si no, pregúntese qué tan rápido podría obtener respuestas a estas preguntas a las 2 a. m. en medio de una crisis.
Las siguientes subsecciones cubren puntos de datos importantes que normalmente me interesan para un problema de rendimiento de la CPU.
- ¿Cuántos sockets y núcleos?
- ¿Está habilitado Hyper-Threading?
- ¿Cuál es el modelo de procesador, la arquitectura (32 bits/64 bits)?
- ¿Es un invitado virtual?
- Si es así, ahora también le interesarán los detalles sobre el anfitrión y los demás invitados virtuales con los que comparte recursos.
- ¿Hay alguna configuración relacionada con la CPU en vigor?
- Por ejemplo, CPU Hyper-V
- ¿Cuántas vCPU se asignan a los invitados?
- ¿Cuántas vCPU tiene este invitado?
- ¿El invitado migró recientemente a un nuevo host antes del problema?
- Configuración del grado máximo de paralelismo
- Umbral de costo para la opción de paralelismo
- Configuración de afinidad del procesador
- Configuración de aumento de prioridad
- Configuración máxima de subprocesos de trabajo
- Configuración de agrupación ligera
- ¿Cuál es la configuración de opciones de energía? (nivel de SO, host de VM o controlado por BIOS)
- ¿Alto rendimiento, equilibrado, ahorro de energía?
- ¿Está configurado más allá de la configuración predeterminada?
- ¿Ve alguna advertencia o error inusual?
Detalles del servidor físico
Detalles del servidor virtual
Reserva, reserva de CPU de VMware, peso relativo de CPU de Hyper-V y recursos compartidos de CPU de VMware.
Parámetros de configuración de la instancia de SQL Server
Las primeras tres configuraciones pueden requerir más discusión. Rara vez hay absolutos con respecto a estos ajustes.
Con respecto a las últimas tres configuraciones, como "aumento de prioridad", si veo que no tienen valores predeterminados, definitivamente presionaré para obtener más información e historial.
Configuración de opciones de energía de la CPU
La configuración de las opciones de energía por debajo de "Alto rendimiento" sigue siendo muy común y no debe ignorarse en los servidores que alojan instancias de SQL Server.
Configuración del regulador de recursos
Todavía encuentro que es raro encontrar clientes que usen esta función, pero es fácil validar si se está usando y valdrá la pena por las veces que se configura más allá de la configuración predeterminada.
Registro de errores de SQL Server y registros de eventos de Windows
¿Por qué buscar en los registros de errores y eventos un problema de CPU? A veces, los problemas ascendentes pueden causar problemas de rendimiento descendente en SQL Server. No desea perder el tiempo ajustando una consulta o agregando un nuevo índice cuando está aguas arriba. El problema de la causa raíz es un problema de degradación del componente de hardware.
Responda "¿Es SQL Server?"
Suena obvio cuando lo pregunto, pero realmente no desea dedicar una cantidad significativa de tiempo a solucionar un problema de CPU alta en SQL Server si el culpable no es realmente SQL Server.
En su lugar, tómese un momento para verificar qué proceso consume la mayor cantidad de CPU. Hay varias opciones para elegir, que incluyen:
- Proceso:% de tiempo de usuario (modo de usuario)
- Proceso:% de tiempo privilegiado (modo kernel)
- Administrador de tareas
- Explorador de procesos
- Información reciente de la CPU a través de sys.dm_os_ring_buffers o la sesión de estado del sistema para las instancias específicas de SQL Server que se ejecutan en el sistema
Si se trata de SQL Server y tiene varias instancias de SQL Server para elegir, asegúrese de solucionar los problemas de la instancia correcta de SQL Server en el host. Hay algunas formas de hacer esto, incluido el uso de SELECT SERVERPROPERTY('processid')
para obtener el PID y luego asociarlo al Administrador de tareas o al Explorador de procesos.
Una vez que haya confirmado que es SQL Server, ¿observa un tiempo de usuario elevado o tiempo privilegiado (del núcleo)? Nuevamente, esto se puede confirmar a través de Proceso:% de tiempo privilegiado (objeto sqlservr) y también Administrador de tareas de Windows o Explorador de procesos.
Si bien los problemas de tiempo de kernel alto deberían ser raros, aún requieren diferentes rutas de solución de problemas que los problemas de solución de problemas de CPU de tiempo de usuario estándar. Algunas causas potenciales de tiempo de kernel alto incluyen controladores de filtro defectuosos (antivirus, servicios de encriptación), actualizaciones de firmware y controladores desactualizados o faltantes, o componentes de E/S defectuosos.
Identificar consumidores de CPU
Una vez que haya validado qué instancia de SQL Server está impulsando el uso de la CPU en el tiempo del usuario en el sistema, hay muchos ejemplos de consultas preestablecidas en la web que podría usar.
A continuación se muestra una lista de los DMV que las personas suelen utilizar de diversas formas durante un problema de rendimiento. Estructuré esto en un formato de preguntas y respuestas para ayudar a enmarcar por qué querrías acceder a ellos.
- sys.dm_exec_requests
- sys.dm_exec_sql_text
- sys.dm_exec_sessions
- sys.dm_exec_conexiones
- sys.dm_exec_query_plan
- sys.dm_os_waiting_tasks
- sys.dm_exec_query_stats
- Agregar por total_worker_time
- Definir promedios con conteo_ejecución
- Si hay cargas de trabajo ad hoc, puede agrupar por query_hash
- Utilice plan_handle con sys.dm_exec_query_plan para tomar el plan
- sys.dm_os_tasks
- Ordenado por session_id, request_id
- sys.dm_exec_query_plan
- Observe los operadores del plan, pero tenga en cuenta que este es solo el plan estimado
- sys.dm_exec_query_stats
- Filtrar total_elapsed_time menos que total_worker_time
- Pero tenga en cuenta que esto puede ser un falso negativo para escenarios de bloqueo, donde la duración se infla debido a una espera en el recurso
¿Qué solicitudes se están ejecutando en este momento y cuál es su estado?
¿Qué está ejecutando?
¿De dónde es?
¿Cuál es su plan estimado? (pero tenga cuidado de triturar xml en un sistema que ya tiene restricciones de CPU)
¿Quién está esperando un recurso y qué está esperando?
¿Qué consultas han ocupado la mayor parte del tiempo de CPU desde el último reinicio?
¿Esta consulta utiliza paralelismo?
Haz coincidir el patrón y resuelve
Probablemente se esté riendo de este paso en particular, ya que este puede ser el más complicado (y es otra razón por la cual los profesionales de SQL Server tienen un empleo remunerado). Hay varios patrones diferentes y resoluciones asociadas, así que terminaré esta publicación con una lista de los controladores de problemas de rendimiento de la CPU más comunes que he visto en los últimos años:
- Operaciones de E/S altas (y en mi experiencia, este es el controlador más común de la CPU)
- Problemas de estimación de cardinalidad (y mala calidad del plan de consulta asociado)
- Paralelismo inesperado
- Compilación/recompilación excesiva
- Llamadas UDF de cálculo intensivo, operaciones de trituración
- Operaciones fila por fila agonizantes
- Actividades de mantenimiento simultáneas (por ejemplo, ACTUALIZAR estadísticas con FULLSCAN)
Cada área que he identificado tiene un gran cuerpo de trabajo asociado para investigar. En términos de recursos consolidados, sigo pensando que uno de los mejores sigue siendo el artículo técnico "Solución de problemas de rendimiento en SQL Server 2008" escrito por Sunil Agarwal, Boris Baryshnikov, Keith Elmore, Juergen Thomas, Kun Cheng y Burzin Patel.
Resumen
Al igual que con cualquier metodología, existen límites para su utilización y áreas en las que está justificado improvisar. Tenga en cuenta que no estoy sugiriendo que los pasos que describí en esta publicación se usen como un marco rígido, sino que considérelos como un punto de partida para sus esfuerzos de resolución de problemas. Incluso los profesionales de SQL Server con mucha experiencia pueden cometer errores de novato o verse sesgados por sus experiencias más recientes en la resolución de problemas, por lo que contar con una metodología mínima puede ayudar a evitar la resolución del problema equivocado.