27
3.1 Choix de l’architecture matérielle
L’option « affinity mask » vous permet de n’attribuer à SQL Server que certains
processeurs. La valeur par défaut, 0, indique que tous les CPU sont utilisés. Pour spécifier seulement certains processeurs, attribuez un entier correspondant au masque
de bits représentant, du bit de poids faible au bit de poids fort, le ou les processeurs à
utiliser. Par exemple, pour n’utiliser que les processeurs 0, 2 et 4, attribuez la valeur
binaire 00010101, donc 21 en décimal.
Ce masque d’affinité ne peut donc gérer que 32 processeurs, ce qui est de toute
façon la limite de Windows Server 2003 32 bits. Sur les architectures 64 bits, une
option supplémentaire est disponible : affinity64 mask pour l’affinité sur
32 processeurs supplémentaires.
À moins que vous n’ayez à libérer des processeurs pour une autre application (par
exemple une autre instance de SQL Server), il vaut mieux laisser SQL Server utiliser
tous les processeurs à disposition. Dans le cas d’un système virtualisé, que nous verrons plus loin, ce sera de toute manière à la machine virtuelle de gérer les processeurs
physiques qu’elle utilise, donc ceci ne concerne pas cette section.
L’option « max degree of parallelism » indique, sur le nombre de processeurs défini
dans l’affinité, combien pourront être enrôlés dans la parallélisation d’une même
requête. La valeur par défaut, 0, indique que tous les CPU peuvent être utilisés.
Cette option modifie le comportement de SQL Server pour l’exécution de toutes les
requêtes. Exemple :
EXEC sp_configure 'max degree of parallelism', 2
Pour permettre une parallélisation sur deux processeurs au maximum.
Lorsqu’une requête est parallélisée, elle doit utiliser le nombre de processeurs
indiqué dans « max degree of parallelism », pas moins. En d’autres termes, si vous laissez SQL Server paralléliser sans limite sur un système comportant beaucoup de processeurs, tous les processeurs devront prendre en charge la requête, et le coût afférant
à la synchronisation entre les processeurs sera sûrement plus important que le gain
de performance de l’exécution en parallèle, faisant donc plus de mal que de bien.
De plus, le parallélisme peut poser problème sur des processeurs utilisant la technologie d’hyper-threading. Cette technologie propriétaire d’Intel, intégrée aux processeurs Pentium 4, est moins utilisée aujourd’hui mais pourrait faire son retour dans
la future architecture « Nehalem ». Elle permet sous certaines conditions d’améliorer les performances d’applications multi-threadées. Un processeur hyper-threadé est vu
par Windows comme deux processeurs 1 , et SQL Server peut tenter de paralléliser
une requête sur ce qui représente en réalité le même processeur physique. On obtiendra ainsi un ralentissement au lieu d’une amélioration, en provoquant des attentes
inter-threads. Ces ralentissements pourront se constater grâce à un type particulier
d’attente (wait). Nous reviendrons en détail sur la détection des attentes dans le
chapitre 7. Sachez pour l’instant que vous pouvez obtenir des statistiques d’attentes
1. SQL Server utilise le membre de structure SYSTEM_INFO.dwNumberofProcessors de l’API
Windows pour connaître le nombre de processeurs. Cette propriété retourne le nombre total de
processeurs physiques et logiques
3.1 Choix de l’architecture matérielle
L’option « affinity mask » vous permet de n’attribuer à SQL Server que certains
processeurs. La valeur par défaut, 0, indique que tous les CPU sont utilisés. Pour spécifier seulement certains processeurs, attribuez un entier correspondant au masque
de bits représentant, du bit de poids faible au bit de poids fort, le ou les processeurs à
utiliser. Par exemple, pour n’utiliser que les processeurs 0, 2 et 4, attribuez la valeur
binaire 00010101, donc 21 en décimal.
Ce masque d’affinité ne peut donc gérer que 32 processeurs, ce qui est de toute
façon la limite de Windows Server 2003 32 bits. Sur les architectures 64 bits, une
option supplémentaire est disponible : affinity64 mask pour l’affinité sur
32 processeurs supplémentaires.
À moins que vous n’ayez à libérer des processeurs pour une autre application (par
exemple une autre instance de SQL Server), il vaut mieux laisser SQL Server utiliser
tous les processeurs à disposition. Dans le cas d’un système virtualisé, que nous verrons plus loin, ce sera de toute manière à la machine virtuelle de gérer les processeurs
physiques qu’elle utilise, donc ceci ne concerne pas cette section.
L’option « max degree of parallelism » indique, sur le nombre de processeurs défini
dans l’affinité, combien pourront être enrôlés dans la parallélisation d’une même
requête. La valeur par défaut, 0, indique que tous les CPU peuvent être utilisés.
Cette option modifie le comportement de SQL Server pour l’exécution de toutes les
requêtes. Exemple :
EXEC sp_configure 'max degree of parallelism', 2
Pour permettre une parallélisation sur deux processeurs au maximum.
Lorsqu’une requête est parallélisée, elle doit utiliser le nombre de processeurs
indiqué dans « max degree of parallelism », pas moins. En d’autres termes, si vous laissez SQL Server paralléliser sans limite sur un système comportant beaucoup de processeurs, tous les processeurs devront prendre en charge la requête, et le coût afférant
à la synchronisation entre les processeurs sera sûrement plus important que le gain
de performance de l’exécution en parallèle, faisant donc plus de mal que de bien.
De plus, le parallélisme peut poser problème sur des processeurs utilisant la technologie d’hyper-threading. Cette technologie propriétaire d’Intel, intégrée aux processeurs Pentium 4, est moins utilisée aujourd’hui mais pourrait faire son retour dans
la future architecture « Nehalem ». Elle permet sous certaines conditions d’améliorer les performances d’applications multi-threadées. Un processeur hyper-threadé est vu
par Windows comme deux processeurs 1 , et SQL Server peut tenter de paralléliser
une requête sur ce qui représente en réalité le même processeur physique. On obtiendra ainsi un ralentissement au lieu d’une amélioration, en provoquant des attentes
inter-threads. Ces ralentissements pourront se constater grâce à un type particulier
d’attente (wait). Nous reviendrons en détail sur la détection des attentes dans le
chapitre 7. Sachez pour l’instant que vous pouvez obtenir des statistiques d’attentes
1. SQL Server utilise le membre de structure SYSTEM_INFO.dwNumberofProcessors de l’API
Windows pour connaître le nombre de processeurs. Cette propriété retourne le nombre total de
processeurs physiques et logiques