Alto CXPACKET y LATCH_EX espera

Tengo algunos problemas de rendimiento con un sistema de procesamiento de datos en el que estoy trabajando. He recopilado estadísticas de espera de un peroide de una hora que muestran una gran cantidad de eventos de espera CXPACKET y LATCH_EX.

El sistema consta de 3 servidores SQL de procesamiento que realizan una gran cantidad de cálculos y cálculos numéricos y luego alimentan los datos en un servidor central de clúster. Los servidores de procesamiento pueden tener hasta 6 trabajos ejecutándose cada uno a la vez. Estas estadísticas de espera son para el clúster central que creo que está causando un cuello de botella. El servidor central del clúster tiene 16 núcleos y 64 GB de RAM. MAXDOP se establece en 0.

Supongo que CXPACKET es de las múltiples consultas paralelas que se ejecutan, sin embargo, no estoy seguro de lo que indica el evento de espera LATCH_EX. ¿De lo que he leído esto podría ser una espera sin búfer?

¿Alguien puede sugerir cuál sería la causa de este tipo de estadísticas de espera y qué curso de acción debería tomar para investigar la causa raíz de este problema de rendimiento?

Los resultados de la consulta superior son las estadísticas de espera totales y el resultado de la consulta inferior son las estadísticas durante el período de 1 hora

CXPACKET se puede acompañar con un LATCH_XX (posiblemente con PAGEIOLATCH_XX o SOS_SCHEDULER_YIELD también). Si este es el caso (y creo que lo es, según la pregunta), entonces el valor MAXDOP debe reducirse para adaptarse a su hardware.

Además de esto, aquí hay algunos pasos más recomendados para diagnosticar la causa de los altos valores de las estadísticas de espera de CXPACKET (antes de cambiar algo en SQL Server):

• No establezca MAXDOP en 1, ya que esta nunca es la solución.

• Investigue la consulta y el historial de CXPACKET para comprender y determinar si es algo que ocurrió solo una o dos veces, ya que podría ser solo la excepción en el sistema que normalmente funciona correctamente

• Verifique los índices y estadísticas en las tablas utilizadas por la consulta y asegúrese de que estén actualizados

• Verifique el Umbral de costo para paralelismo (CTFP) y asegúrese de que el valor utilizado sea apropiado para su sistema

• Compruebe si el CXPACKET está acompañado de un LCK_M_XX (generalmente acompañado de IO_COMPLETION y ASYNC_IO_COMPLETION). Si este es el caso, entonces el paralelismo no es el cuello de botella. Solucione los problemas de esas estadísticas de espera para encontrar la causa raíz del problema y la solución

Si realmente necesita comprender el tipo de espera CXPACKET en profundidad, le aconsejaría leer el artículo de resolución de problemas del tipo de espera CXPACKET en el artículo de SQL Server

Leer Diagnóstico y resolución de retención de pestillos en SQL Server , es el documento más completo sobre el tema. Tendrás que cavar sys.dm_os_latch_statsy ver en qué tipo de pestillo es la contención.

Vea si leer Cómo analizar el rendimiento de SQL Server lo ayuda de alguna manera.

Además de leer los enlaces proporcionados anteriormente y lo más probable es que cambie su configuración de "Grado máximo de paralelismo" de 0 a algo así como 8, querrá reducir cuáles de sus consultas van en paralelo y cuál es su costo.

Después de ver el impacto de este cambio, también puede considerar modificar su "Umbral de costo para paralelismo" para ajustar lo que irá en paralelo.

Aquí hay un gran video de Brent Ozar que lo ayudará: Dominar el arte de CXPACKET y MAXDOP

Su objetivo es <= 50% de tiempo de espera para CXPACKET. ¡¡Buena suerte!!