SQL Server – Modification MAXDOP: comment mesurer l'effet sur les performances?

Dans un environnement où de nombreuses requêtes volumineuses sont exécutées, CXPacket apparaît toujours en haut de la list des attentes, et ce n'est pas un problème. Le seul problème est quand cela commence à monter en flèche sur ce que vos attentes normales sont. Dans ces cas, cela signifie généralement que vos statistics sont si éloignées qu'elles n'obtiennent pas un plan d'exécution précis et que vous devez searchr une meilleure maintenance de l'index.

D'après ce que vous avez dit, il n'y a pas de raison que j'abaisse MaxDOP sur cette seule base. Au lieu de cela, j'irais avec le conseil typique de jusqu'à 8 avec pas plus que le nombre de cœurs dans un seul nœud NUMA pour OLTP.

Dans votre cas, je commencerais à regarder vos requêtes les plus chères en utilisant Query Stats avec vos requêtes les plus volumineuses en fonction d'une trace côté server . Si vous êtes en mesure de régler les plus grands délinquants que vous voyez ici, vous aurez un server plus rapide avec un type d'attente CXPacket abaissé.

Comme un peu d'une clause de non-responsabilité, je suis l'auteur de l'article sur les statistics d'attente que vous avez mentionné ainsi que les articles liés à cette réponse.

N'hésitez pas à répondre ici pour cette question ou sur mon blog pour tous les autres qui viennent.

Les attentes de CXPACKET n'indiquent pas nécessairement un problème de parallélisme – c'est généralement un symptôme d'un autre problème.

Lorsqu'une requête est parallèle, disons à travers 10 threads, et que l'un de ces 10 threads prend plus de time que les autres pour terminer son travail, les 9 autres threads vont accumuler des attentes CXPACKET.

Quels autres types d'attentes élevées voyez-vous?

Basé sur ce qui précède, il semble que vous pourriez avoir un utilitaire pour vous aider à surveiller les performances des requêtes.

Je peux suggérer ApexSQL Monitor (un outil commercial, mais offre un essai gratuit) qui peut stocker des informations historiques, de sorte que vous pouvez consulter les détails avant et après la réduction de MAXDOP – et vous pouvez examiner la performance globale de la requête.

En plus de cela, vous pouvez également find une bonne explication sur les causes possibles de CXPACKET et MAXDOP dans cet article http://www.sqlshack.com/troubleshooting-the-cxpacket-wait-type-in-sql-server/ . Voici quelques éléments keys de l'article:

Les étapes qui sont recommandées pour diagnostiquer la cause des valeurs de statistics d'attente CXPACKET élevées (avant de faire n'importe quelle réaction de réflexe et de modifier quelque chose sur SQL Server):

• Ne définissez pas MAXDOP sur 1, car ce n'est jamais la solution
• Étudiez la requête et l'historique de CXPACKET pour comprendre et déterminer si quelque chose s'est produit une ou deux fois, car il pourrait s'agir de l'exception dans le système qui fonctionne normalement correctement.
• Vérifiez les index et les statistics sur les tables utilisées par la requête et assurez-vous qu'elles 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 LATCH_XX (éventuellement avec PAGEIOLATCH_XX ou SOS_SCHEDULER_YIELD). Si c'est le cas, la valeur MAXDOP doit être réduite pour s'adapter à votre matériel
• 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, alors le parallélisme n'est pas le goulot d'étranglement. Résolvez ces statistics d'attente pour find la cause première du problème et de la solution