Meilleures pratiques de parallélisme

Quelles sont les meilleures pratiques pour établir le parallélisme en général? Je sais que SQL Server 0utilise par défaut tous les processeurs disponibles, mais dans quel cas voudriez-vous changer ce comportement par défaut?

Je me souviens avoir lu quelque part (je vais devoir chercher cet article) que pour les charges de travail OLTP, vous devez désactiver le parallélisme (définissez maxdop sur 1). Je ne pense pas que je comprends parfaitement pourquoi vous feriez cela.

Quand voudriez-vous garder maxdop jusqu'à SQL Server (0)? Quand désactiveriez-vous le parallélisme (1)? Quand déclareriez-vous explicitement le maxdop à un nombre particulier de processeurs?

Qu'est-ce qui cause le parallélisme?

Vous ne voulez généralement pas désactiver le parallélisme car cela le désactivera également pour les tâches d'administration. Votre meilleur pari est de corriger les requêtes qui provoquent le parallélisme en ajoutant ou en corrigeant des index ou en apportant des modifications complètes au schéma.

Sur la base de vos questions mises à jour ...

Certaines personnes changeront MAXDOP à 1 pour les applications conçues par le fournisseur car elles ne peuvent pas contrôler la base de données ou le schéma et elles ne veulent pas qu'une seule requête prenne le contrôle de l'ensemble du système.

Personnellement, je garde toujours MAXDOP à 0, sauf dans de rares cas.

Le parallélisme est provoqué par une seule opération dans un plan d'exécution ayant un coût d'exécution qui dépasse un paramètre prédéfini (le seuil de coût pour le paramètre de parallélisme). Lorsque cela se produit, SQL Server démarre le parallélisme afin de pouvoir multi-threader la demande dans le but d'accélérer le processus. La valeur par défaut du seuil de coût pour le parallélisme est 5. Dans de nombreuses plates-formes OLTP, vous souhaiterez augmenter ce nombre à 30 ou 40 afin que le parallélisme ne se déclenche que pour les requêtes très coûteuses.

Je n'ai jamais vu la nécessité de désactiver ou de modifier les paramètres de parallélisme de tout mon temps avec SQL Server (le dernier millénaire, SQL Sever 6.5)

Dans la continuité de la réponse de @StanleyJohns ...
Un système OLTP avec des requêtes courtes et précises ne devrait jamais atteindre le seuil de coût ( "seuil de coût pour le parallélisme" ), donc cela ne devrait pas avoir d'importance. Si vous avez des requêtes qui vont en parallèle, alors pourquoi la restreindriez-vous en fonction de quelque chose qui n'a pas été prouvé

Je n'ai pas encore vu un système OLTP pur aussi. À l'extrême, il y en a peut-être, mais le système moyen en fait également rapport; que ce soit en journée ou pendant la nuit. Ces requêtes sont plus susceptibles d'aller en parallèle et d'en bénéficier.

Avec autant de cœurs CPU disponibles aujourd'hui, il est sans doute judicieux de définir le "degré de parallélisme maximal" global si vous pouvez mesurer et remarquer une différence.

Comme je l'ai dit, ma suggestion est de ne rien faire . Similaire à @mrdenny, mais j'inclurais «il n'y a pas de système OLTP pur»

Cela dit, il peut y avoir un certain kilométrage à désactiver les cœurs hyperthreadés au niveau du BIOS, mais c'est une question différente ...

Veuillez également consulter

• ma douzaine de réponses SO: https://stackoverflow.com/search?tab=votes&q=user%3a27535%20parallelism
• Traitement des requêtes parallèles sur MSDN

Qu'est-ce qui cause le parallélisme?: Un paramètre est appelé cost threshold for parallelism. Une fois ce seuil dépassé, le parallélisme est utilisé (si les conditions préalables sont remplies).

La nature d'un système OLTP est d'avoir un grand nombre de transactions rapides et courtes. L'utilisation du parallélisme augmente parfois le temps de traitement des requêtes, car la requête sera divisée pour être traitée en parallèle, puis recousue avant d'être renvoyée. Par conséquent, vous verrez des suggestions pour définir maxdop à 1.

Un avantage de définir maxdop à 1 est que le parallélisme est désactivé par défaut, mais vous pouvez l'activer au niveau de la requête à l'aide de query hints.

Pour les systèmes d'entrepôt de données ou les systèmes OLAP où des jeux de résultats volumineux sont renvoyés, il peut être avantageux de fractionner la requête à l'aide du parallélisme. Cela permet à la requête d'exploiter les cœurs disponibles pour réduire le temps de traitement des requêtes.

J'ai vu une requête complexe divisée en plusieurs processus qui prend des heures à exécuter - vous pouvez généralement voir cela dans sp_who2 comme plusieurs entrées avec le même spid.

Le changer en maxdop 1 et la requête exécutée en moins d'une minute.

La leçon ici est que le moteur ne fait pas toujours les choses correctement en matière de parallélisme.

Nous avons beaucoup de serveurs avec 4 cœurs et certains avec 8 cœurs. Je recommande avec si peu de cœurs que le parallélisme (MAXDOP) soit défini sur 1 afin d'éviter les attentes sur le processeur (et également les problèmes de délai) pour les utilisateurs des systèmes OLTP. Pour les serveurs OLAP ou de génération de rapports, avec si peu de cœurs, je recommande de définir MAXDOP sur 2 et de définir le seuil de coût sur 30 (cela peut être supérieur ou un peu inférieur pour votre scénario) afin que seules les requêtes les plus lourdes utilisent le parallélisme.