Attentes CXPACKET et LATCH_EX élevées

J'ai des problèmes de performances avec un système de traitement de données sur lequel je travaille. J'ai rassemblé des statistiques d'attente à partir d'une période d'une heure qui montre une grande quantité d'événements d'attente CXPACKET et LATCH_EX.

Le système se compose de 3 serveurs SQL de traitement qui effectuent beaucoup de calculs et de calculs de nombres, puis introduisent les données dans un serveur de cluster central. Les serveurs de traitement peuvent avoir jusqu'à 6 tâches exécutées chacune à la fois. Ces statistiques d'attente concernent le cluster central qui, je pense, provoque un goulot d'étranglement. Le serveur de cluster central possède 16 cœurs et 64 Go de RAM. MAXDOP est défini sur 0.

Je suppose que le CXPACKET provient des multiples requêtes parallèles en cours d'exécution, mais je ne suis pas sûr de ce que l'événement d'attente LATCH_EX indique. D'après ce que j'ai lu, cela pourrait être une attente sans tampon?

Quelqu'un peut-il suggérer quelle serait la cause de ce genre de statistiques sur les attentes et quelle ligne de conduite devrais-je adopter pour enquêter sur la cause première de ce problème de performances?

Les résultats de la requête supérieure sont les statistiques d'attente totale et le résultat de la requête inférieure est les statistiques sur la période d'une heure

CXPACKET peut être accompagné d'un LATCH_XX (éventuellement avec PAGEIOLATCH_XX ou SOS_SCHEDULER_YIELD également). Si tel est le cas (et je pense que c'est le cas, sur la base de la question), la valeur MAXDOP doit être réduite pour s'adapter à votre matériel.

En plus de cela, voici quelques étapes plus recommandées pour diagnostiquer la cause des valeurs élevées des statistiques d'attente CXPACKET (avant de changer quelque chose sur SQL Server):

• Ne définissez pas MAXDOP sur 1, car ce n'est jamais la solution

• Examinez la requête et l'historique CXPACKET pour comprendre et déterminer s'il s'agit de quelque chose qui s'est produit une ou deux fois, car il pourrait s'agir de l'exception du système qui fonctionne normalement correctement.

• Vérifiez les index et les statistiques des tables utilisées par la requête et assurez-vous qu'ils sont à jour

• Vérifiez le seuil de coût pour le parallélisme (CTFP) et assurez-vous que la valeur utilisée est appropriée pour votre système

• Vérifiez si le CXPACKET est accompagné d'un LCK_M_XX (généralement accompagné de IO_COMPLETION et ASYNC_IO_COMPLETION). Si tel est le cas, le parallélisme n'est pas le goulot d'étranglement. Dépannez ces statistiques d'attente pour trouver la cause première du problème et de la solution

Si vous avez vraiment besoin de comprendre le type d'attente CXPACKET en profondeur, je vous conseille de lire le dépannage du type d'attente CXPACKET dans SQL Server article

Lire Diagnostiquer et résoudre les conflits de verrous sur SQL Server est le document le plus complet sur le sujet. Vous devrez creuser sys.dm_os_latch_statset voir quel type de verrou est en conflit.

Voyez si la lecture Comment analyser les performances de SQL Server vous aide en aucune façon.

En plus de lire les liens fournis ci-dessus et de changer très probablement votre paramètre "Max Degree of Parallelism" de 0 à quelque chose comme 8, vous voudrez préciser lesquelles de vos requêtes vont en parallèle et quel est leur coût.

Après avoir vu l'impact de ce changement, vous pouvez également envisager de modifier votre «seuil de coût pour le parallélisme» pour affiner ce qui se passera en parallèle.

Voici une excellente vidéo de Brent Ozar qui vous aidera: Maîtriser l'art de CXPACKET et MAXDOP

Votre objectif est de <= 50% pour cent de temps d'attente pour CXPACKET. Bonne chance!!