[SQL Server] Performance tuning : intérêt du paramétrage du MAXDOP

Ce billet présente très brièvement le MAXDOP (Maximum Degree Of Parallelism) sous SQL Server.

Présentation élémentaire du MAXDOP

S’il y a plusieurs processeurs sur la machine, il est idéal de configurer le MAXDOP de façon à ce que SQL Server ne s’accapare pas tous les CPUs afin de ne pas engendrer d’éventuels blocages (CXPACKET élevé,…).

Par défaut, quand SQL Server tourne sur une machine riche en CPUs, il détecte le meilleur degré de parallélisme qui est, en fait, le nombre de processeurs utilisés (ou à utiliser) pour exécuter une simple requête pour chaque plan d’exécution parallèle. Ce comportement est matérialisé par une valeur de MAXDOP égale, par défaut, à 0.

Quelle valeur de MAXDOP est la mieux adaptée ?

De manière générale, la règle suivante est à appliquer selon les 5 conditions suivantes :

  • S’il n’y a qu’un seul et unique processeur, on ne fait rien du tout.
  • Si le nombre de processeurs est compris entre 4 et 8, on le divise par 2 et on affecte le résultat au MAXDOP.
  • Si le nombre de processeurs sur la machine est supérieur à 8, on donne 8 comme valeur de MAXDOP.
  • Si les processeurs sont « hyperthreadés[1] », la valeur de MAXDOP ne doit pas dépasser le nombre de processeurs de la machine.
  • Si les processeurs sont sur une machine qui a NUMA[2] configuré, la valeur de MAXDOP ne doit pas dépasser le nombre d’UCs affectés à chaque nœud NUMA.

Notez que pour désactiver le MAXDOP, il suffira de lui indiquer une valeur égale à 1.

En outre, dans le cas d’un datawarehouse, il est généralement souhaitable de laisser la valeur de MAXDOP à 0 du fait de la complexité des requêtes exécutées, ces dernières incluant souvent un très grand nombre de jointures et traitant un large ensemble de données,

Pour aller plus loin…

Vous pouvez jeter un coup d’œil ici, pour avoir un exemple de paramétrage du MAXDOP d’une instance OLTP SQL Server. Dans le futur, nous étudierons l’influence du MAXDOP sur les performances des requêtes.


[1]Le hyperthreading n’est généralement pas recommandé au niveau d’un serveur hébergeant SQL Server : http://blogs.msdn.com/b/slavao/archive/2005/11/12/492119.aspx et http://blogs.msdn.com/b/sqladventurer/archive/2012/07/11/hyperthreading-turbo-boost-sql-server-and-you.aspx. Toutefois, avec la prolifération de processeurs de nouvelle génération possèdant une meilleure mémoire cache L3 (Nehalem, Westmere,…), il est de bon ton d’effectuer quelques tests au préalable, histoire de voir si le hyperthreading peut poser problème ou non. En surveillant, par exemple, la durée moyenne de consommation CPU des transactions, les statistiques I/O,…

[2]NUMA (Non Uniform Memory Access ou Non Uniform Memory Architecture) est un système multiprocesseur dans lequel les zones mémoire sont séparées et placées en différents endroits (et sur différents bus). Vis-à-vis de chaque processeur, les temps d’accès diffèrent donc suivant la zone mémoire accédée. Voir ici.

Publicités

Un commentaire sur “[SQL Server] Performance tuning : intérêt du paramétrage du MAXDOP

  1. […] génère trop de threads en attente conduisant ainsi à des deadlocks, envisagez un passage du MAXDOP à […]

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s