Je n'ai jamais bien compris l'usage de MAXDOP . Je sais que cela accélère la requête et que c'est le dernier élément que je peux utiliser pour l'optimisation des requêtes.
Cependant, ma question est la suivante : quand et où est-il le plus approprié de l'utiliser dans une requête ?
Comme l'a mentionné Kaboing, MAXDOP(n) contrôle en fait le nombre de cœurs de CPU utilisés dans le processeur de requêtes.
Sur un système complètement inactif, SQL Server tentera de tirer les tables en mémoire aussi rapidement que possible et de les joindre en mémoire. Il se peut que, dans votre cas, il soit préférable d'effectuer cette opération avec un seul processeur. Cela pourrait avoir le même effet que d'utiliser OPTION (FORCE ORDER) qui force l'optimiseur de requêtes à utiliser l'ordre des jointures que vous avez spécifié. Dans certains cas, j'ai vu OPTION (FORCE PLAN) réduire une requête de 26 secondes à 1 seconde de temps d'exécution.
Books Online poursuit en disant que les valeurs possibles pour MAXDOP sont :
0 - Utilise le nombre réel de CPU disponibles en fonction de la charge de travail actuelle du système. Il s'agit de la valeur par défaut et du paramètre recommandé.
1 - Supprime la génération de plans parallèles. L'opération sera exécutée en série.
2-64 - Limite le nombre de processeurs à la valeur spécifiée. Un nombre inférieur de processeurs peut être utilisé en fonction de la charge de travail actuelle. Si une valeur supérieure au nombre de processeurs disponibles est spécifiée, le nombre réel de processeurs disponibles est utilisé.
Je ne suis pas sûr de la meilleure utilisation de MAXDOP Cependant, je dirais que si vous avez une table avec 8 partitions, vous voudriez spécifier MAXDOP(8) en raison des limitations d'E/S, mais je peux me tromper.
Voici quelques liens rapides que j'ai trouvés sur MAXDOP :
Livres en ligne : Degré de parallélisme
Directives générales à utiliser pour configurer l'option MAXDOP
Il s'agit d'une divagation générale sur le parallélisme dans SQL Server, qui ne répond peut-être pas directement à votre question.
De Livres en ligne, sur MAXDOP :
Définit le nombre maximum de proc le processeur de requêtes peut utiliser pour exécuter une seule déclaration d'index. Moins de processeurs peuvent être utilisés en fonction de la charge de travail actuelle du système.
Voir Le blog de Rickie Lee sur le parallélisme et le type d'attente CXPACKET. C'est assez intéressant.
En général, dans une base de données OLTP, je pense que si une requête est si coûteuse qu'elle doit être exécutée sur plusieurs processeurs, la requête doit être réécrite en quelque chose de plus efficace.
Pourquoi obtenez-vous de meilleurs résultats en ajoutant MAXDOP(1) ? Difficile à dire sans les plans d'exécution réels, mais cela pourrait être aussi simple que le plan d'exécution est totalement différent que sans l'OPTION, par exemple en utilisant un index différent (ou plus probablement) en faisant des jointures différentes, en utilisant des jointures MERGE ou HASH.
Par ailleurs, MAXDOP peut apparemment être utilisé comme solution de rechange à un bogue potentiellement dangereux :
Les valeurs d'identité renvoyées ne sont pas toujours correctes
Il y a quelques bugs de paralizage dans le serveur SQL avec une entrée anormale. L'OPTION(MAXDOP 1) les évitera.
EDIT : Vieux. Mes tests ont été effectués en grande partie sur SQL 2005. La plupart d'entre eux semblent ne plus exister, mais de temps en temps, nous remettons en question l'hypothèse lorsque SQL 2014 fait quelque chose de stupide et nous revenons à l'ancienne méthode et cela fonctionne. Nous n'avons jamais réussi à démontrer qu'il ne s'agissait pas simplement d'une mauvaise génération de plan sur des cas plus récents, car on peut compter sur SQL Server pour utiliser l'ancienne méthode correctement dans les versions plus récentes. Puisque tous les cas étaient des requêtes liées à l'IO, MAXDOP 1 ne fait pas de mal.
Je n'ai pas été en mesure de qualifier complètement les bogues, mais il y en a un en particulier : quand une jointure à gauche est censée correspondre à très peu de % des lignes, on essaie de spooler les deux tables et la jointure en boucle plutôt que la recherche de signet seulement avec la parallélisation activée.
@Joshua, Savez-vous si les bogues sont toujours pertinents pour les versions SQL 2012, 14 ou 16 ?
J'ajoute mes deux cents, sur la base d'un problème de performance que j'ai observé.
Si des requêtes simples sont parelléisées inutilement, cela peut engendrer plus de problèmes que d'en résoudre. Cependant, avant d'ajouter MAXDOP dans la requête comme solution "réflexe", il faut vérifier certains paramètres du serveur.
En Jeremiah Peschka - Cinq paramètres du serveur SQL à modifier , MAXDOP et "COST THRESHOLD FOR PARALLELISM" ( CTFP ) sont mentionnés comme des paramètres importants à vérifier.
Note : Paul White a mentionné max server memory ainsi qu'un paramètre à vérifier, dans une réponse à Problème de performance après la migration de SQL Server 2005 vers 2012 . Un bon article sur le kb à lire est L'utilisation d'une grande quantité de mémoire peut entraîner un plan inefficace dans SQL Server
Jonathan Kehayias - Réglage du "seuil de coût pour le parallélisme" à partir du cache de plan. aide à trouver un bon rapport qualité-prix CTFP .
Pourquoi le seuil de coût du parallélisme est-il ignoré ?
Aaron Bertrand - Six raisons pour lesquelles le parallélisme devrait vous inquiéter a une discussion sur un scénario où MAXDOP est la solution.
Les composants inhibant le parallélisme sont mentionnés dans Paul White - Forcer un plan d'exécution de requêtes parallèles
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
Vous devez inclure la version et le service pack du serveur SQL. Ce problème peut avoir été corrigé dans une version ultérieure...