Quand apporter des modifications au seuil de coût du parallélisme

Lors de l'examen d'un problème de performances, j'ai vu un afflux sur CXPACKETS suggérant que je pourrais avoir besoin de regarder le seuil de coût pour le parallélisme et peut-être le MAXDOP.

Avant d'apporter des modifications drastiques au MAXDOP, j'ai suivi les conseils de beaucoup d'autres, y compris celui de @mrdenny dans la réponse à l' optimisation des performances de CXPACKET Waits pour SQL Server 2008 et la réponse de @ aron-Bertrand dans Dealing with CXPACKET waits - setting threshold cost pour le parallélisme . J'ai ajouté à la maintenance pour mettre à jour les statistiques entièrement tous les soirs. Cela semble être une décision sensée.

Cependant, apporter des modifications au seuil de coût est toujours quelque chose qui me gêne.

À quel moment le seuil de coût du parallélisme devrait-il être modifié? Quelqu'un a-t-il un exemple où (après avoir examiné le coût de ses requêtes et de sa charge de travail), il a modifié ce coût?

S'excuse si c'est quelque chose qui a été répondu dans une question précédente.

Merci!

L'utilisation de MAXDOP = 1 peut être une aide, mais c'est un gros pistolet. Il se peut que le problème réel soit l'utilité des index. Peut-être qu'un index nouveau ou différent résoudrait le problème.

Suite aux commentaires de M. Denny et Aaron Bertrand, avez-vous découvert quelles autres attentes à cet égard étaient probablement la cause des attentes du CXPACKET?

Jonathan Kehayias a suggéré une requête qui pourrait vous aider à évaluer votre expérience de parallélisme et à prendre une décision plus réfléchie. Mais vous devriez également lire la conversation entre Jonathan et Paul White.

https://www.sqlskills.com/blogs/jonathan/tuning-cost-threshold-for-parallelism-from-the-plan-cache/

Je vous suggère de regarder d'abord dans les paramètres MAXDOP car le paramètre par défaut de 0 (utiliser tous les threads disponibles) peut être dangereux car une requête galopante consommant tous les threads disponibles entraînera la famine des threads.

Reportez-vous à ma réponse ici pour savoir comment calculer le paramètre MAXDOP pour votre instance de serveur.

Le seuil de coût du parallélisme fait référence au coût minimal de requête avant que le parallélisme soit pris en compte par l'optimiseur.

Rappelez-vous que les attentes de CXPACKET ne sont que des symptômes dus à un problème lié à la requête - des statistiques obsolètes ou un index manquant entraînant un plan incorrect ou différent.

Vous pouvez utiliser sys.dm_exec_cached_planset sys.dm_exec_query_planDMV pour extraire des informations du cache du plan, comme décrit dans Réglage du «seuil de coût pour le parallélisme» du cache du plan par Jonathan et du seuil de coût pour le parallélisme .

Je suggérerais de conserver la cost threshold for parallelismvaleur par défaut à moins que vous n'ayez épuisé les requêtes de réglage des ressources, de faire la maintenance des index et des statistiques ainsi que de vérifier si vous n'avez pas d'index manquants dont votre requête pourrait bénéficier.

Remarque: le paramètre Maxdop peut également être appliqué au niveau de la requête, OPTION (MAXDOP n)ce qui remplacera le paramètre à l'échelle du serveur.