CXPACKET alto e LATCH_EX attendono

Sto riscontrando alcuni problemi di prestazioni con un sistema di elaborazione dati su cui sto lavorando. Ho raccolto statistiche di attesa da un perido di un'ora che mostrano una grande quantità di eventi di attesa CXPACKET e LATCH_EX.

Il sistema è composto da 3 server SQL di elaborazione che eseguono molti calcoli e calcoli numerici e quindi immettono i dati in un server cluster centrale. I server di elaborazione possono avere fino a 6 processi in esecuzione ciascuno alla volta. Queste statistiche di attesa sono per il cluster centrale che penso stia causando un collo di bottiglia. Il server cluster centrale ha 16 core e 64 GB di RAM. MAXDOP è impostato su 0.

Suppongo che CXPACKET provenga da più query parallele in esecuzione, tuttavia non sono sicuro di cosa indichi l'evento di attesa LATCH_EX. Da quello che ho letto potrebbe essere un'attesa non buffer?

Qualcuno può suggerire quale sarebbe la causa di questo tipo di statistiche sulle attese e quale linea di condotta dovrei prendere per indagare sulla causa principale di questo problema di prestazioni?

I risultati della query principale sono le statistiche di attesa totali e il risultato della query inferiore è le statistiche nel periodo di 1 ora

CXPACKET può essere accompagnato da un LATCH_XX (possibilmente anche con PAGEIOLATCH_XX o SOS_SCHEDULER_YIELD). Se questo è il caso (e credo che lo sia, in base alla domanda), il valore MAXDOP dovrebbe essere abbassato per adattarsi all'hardware.

Oltre a questo, ecco alcuni passaggi più consigliati per diagnosticare la causa di valori elevati di statistiche di attesa CXPACKET (prima di modificare qualcosa su SQL Server):

• Non impostare MAXDOP su 1, poiché questa non è mai la soluzione

• Esamina la query e la cronologia di CXPACKET per capire e determinare se si tratta di qualcosa che si è verificato solo una o due volte, poiché potrebbe essere solo un'eccezione nel sistema che normalmente funziona correttamente

• Controlla gli indici e le statistiche sulle tabelle utilizzate dalla query e assicurati che siano aggiornati

• Controllare la soglia di costo per il parallelismo (CTFP) e assicurarsi che il valore utilizzato sia appropriato per il proprio sistema

• Controllare se CXPACKET è accompagnato da un LCK_M_XX (solitamente accompagnato da IO_COMPLETION e ASYNC_IO_COMPLETION). In questo caso, il parallelismo non è il collo di bottiglia. Risolvi i problemi relativi a tali statistiche di attesa per trovare la causa principale del problema e della soluzione

Se hai davvero bisogno di comprendere il tipo di attesa CXPACKET in modo approfondito, ti consiglio di leggere l'articolo Risoluzione dei problemi relativi al tipo di attesa CXPACKET nell'articolo di SQL Server

Leggi Diagnosi e risoluzione della controversia sui latch in SQL Server , è il documento più completo sull'argomento. Dovrai scavare sys.dm_os_latch_statse vedere su quale tipo di blocco è la contesa.

Verifica se leggere Come analizzare le prestazioni di SQL Server ti aiuta in qualche modo.

Oltre a leggere i link sopra riportati e molto probabilmente cambiare l'impostazione "Max Degree of Parallelism" da 0 a qualcosa come 8, ti consigliamo di restringere quali delle tue query stanno andando in parallelo e quale è il loro costo.

Dopo aver visto l'impatto di questo cambiamento, puoi anche considerare di modificare la "Soglia di costo per il parallelismo" per mettere a punto ciò che andrà in parallelo.

Ecco un ottimo video di Brent Ozar che ti aiuterà: padroneggiare l'arte di CXPACKET e MAXDOP

Il tuo obiettivo è <= 50% percentuale di tempo di attesa per CXPACKET. In bocca al lupo!!