26
Chapitre 3. Optimisation du matériel
données et suffisamment pourvu en RAM, la vitesse du sous-système disque n’est pas
le critère le plus décisif, car la plupart des données lues le seront depuis le cache de
données, en RAM. Dans tous les cas, plus la quantité de RAM est importante,
meilleures seront les performances. En ce qui concerne les CPU, un système multiprocesseurs est aujourd’hui incontournable. SQL Server utilise intensivement le
multi-processing, en répartissant ses requêtes sur des threads de travail, ou en parallélisant la même requête si l’activité de la machine est suffisamment légère pour le
permettre au moment de l’exécution.
3.1.1 Processeur(s)
C’est une évidence, SQL Server utilise activement le multi-processing. N’hésitez pas
à bâtir une machine de huit processeurs ou plus. L’édition standard ne supporte que
quatre CPU. Entendez quatre processeurs physiques (quatre sockets). Si vous utilisez
des processeurs multi-core (dual ou quad), cela augmente le nombre de processeurs
supportés par cette édition. De même, le mode de licence par processeur de SQL
Server est à entendre par socket. Pour quatre quad-core, donc seize processeurs logiques, vous vous acquittez d’une licence de quatre processeurs. Le multi-core est bien
pris en charge, mais, l’hyper-threading peut poser des problèmes : nous le détaillerons
dans la section suivante.
Parallélisme
Les opérations de bases de données, notamment la génération du plan d’exécution et
la restitution de données, sont habituellement gourmandes en temps processeur. Les
serveurs sont aujourd’hui de plus en plus multiprocesseurs, et les processeurs (notamment Intel) modernes intègrent des architectures de multi-threading ou de multi-core,
qui leur permettent de travailler en parallèle. Deux cas de figure sont possibles :
l’exécution en parallèle de requêtes différentes ou l’exécution en parallèle de différentes parties de la même requête. C’est ce deuxième cas de figure qu’on appelle la
parallélisation d’une requête. La décision de paralléliser une requête est prise en
temps réel par le moteur relationnel, selon l’état actuel du système : si l’activité est
faible, et la requête est estimée coûteuse (longue), SQL Server sera plus enclin à
paralléliser que si la requête est simple et que le système est chargé de demandes de
petites requêtes. En d’autres termes, la parallélisation est plus intéressante sur un
système analytique de type OLAP, que sur une base de données transactionnelle très
active, de type site web. Le degré de parallélisme, ainsi que le seuil à partir duquel la
durée estimée d’une requête la classe comme candidate à la parallélisation, sont des
paramètres du système que vous pouvez modifier :
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
EXEC sp_configure 'affinity mask'
EXEC sp_configure 'max degree of parallelism'
EXEC sp_configure 'cost threshold for parallelism'
Chapitre 3. Optimisation du matériel
données et suffisamment pourvu en RAM, la vitesse du sous-système disque n’est pas
le critère le plus décisif, car la plupart des données lues le seront depuis le cache de
données, en RAM. Dans tous les cas, plus la quantité de RAM est importante,
meilleures seront les performances. En ce qui concerne les CPU, un système multiprocesseurs est aujourd’hui incontournable. SQL Server utilise intensivement le
multi-processing, en répartissant ses requêtes sur des threads de travail, ou en parallélisant la même requête si l’activité de la machine est suffisamment légère pour le
permettre au moment de l’exécution.
3.1.1 Processeur(s)
C’est une évidence, SQL Server utilise activement le multi-processing. N’hésitez pas
à bâtir une machine de huit processeurs ou plus. L’édition standard ne supporte que
quatre CPU. Entendez quatre processeurs physiques (quatre sockets). Si vous utilisez
des processeurs multi-core (dual ou quad), cela augmente le nombre de processeurs
supportés par cette édition. De même, le mode de licence par processeur de SQL
Server est à entendre par socket. Pour quatre quad-core, donc seize processeurs logiques, vous vous acquittez d’une licence de quatre processeurs. Le multi-core est bien
pris en charge, mais, l’hyper-threading peut poser des problèmes : nous le détaillerons
dans la section suivante.
Parallélisme
Les opérations de bases de données, notamment la génération du plan d’exécution et
la restitution de données, sont habituellement gourmandes en temps processeur. Les
serveurs sont aujourd’hui de plus en plus multiprocesseurs, et les processeurs (notamment Intel) modernes intègrent des architectures de multi-threading ou de multi-core,
qui leur permettent de travailler en parallèle. Deux cas de figure sont possibles :
l’exécution en parallèle de requêtes différentes ou l’exécution en parallèle de différentes parties de la même requête. C’est ce deuxième cas de figure qu’on appelle la
parallélisation d’une requête. La décision de paralléliser une requête est prise en
temps réel par le moteur relationnel, selon l’état actuel du système : si l’activité est
faible, et la requête est estimée coûteuse (longue), SQL Server sera plus enclin à
paralléliser que si la requête est simple et que le système est chargé de demandes de
petites requêtes. En d’autres termes, la parallélisation est plus intéressante sur un
système analytique de type OLAP, que sur une base de données transactionnelle très
active, de type site web. Le degré de parallélisme, ainsi que le seuil à partir duquel la
durée estimée d’une requête la classe comme candidate à la parallélisation, sont des
paramètres du système que vous pouvez modifier :
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
EXEC sp_configure 'affinity mask'
EXEC sp_configure 'max degree of parallelism'
EXEC sp_configure 'cost threshold for parallelism'