126
Chapitre 5. Analyse des performances
miné par l’option de configuration du serveur « max worker threads ». La valeur par
défaut de cette option est 0, qui correspond à une auto-configuration de SQL Server.
Cette valeur est optimale dans la grande majorité des cas. Si vous avez effectué une
mise à jour directe d’une instance SQL Server 2000 vers 2005, vérifiez que cette
valeur est bien à 0. En effet, en SQL Server 2000, la valeur par défaut était 255, et
elle demeure lors de la mise à jour. L’auto-configuration en SQL Server 2005 suit une
logique relative au nombre de processeurs, expliquée dans les BOL sous l’entrée
« max worker threads Option ». Pour connaître la valeur actuelle sur votre système :
SELECT max_workers_count
FROM sys.dm_os_sys_info
Il est hasardeux d’augmenter le nombre de worker threads, et en général inutile,
voire contre performant 1 . Cette option n’est pas une option intéressante pour augmenter les performances.
Donc, les changements de contexte sont coûteux, mais nécessaires. Des valeurs
comme 10 000 ou 15 000 sont normales. Une augmentation exagérée de context
switches devient un problème, car les processeurs passent trop de leur temps à changer de contexte. Dans ce cas, une augmentation du nombre de processeurs est à envisager. Dans un système en architecture SMP qui comporte beaucoup de processeurs,
où le nombre de changements de contexte est élevé de façon consistante, et où les
processeurs sont en utilisation presque maximum en permanence, vous pouvez
essayer de configurer SQL Server pour l’utilisation de fibres. Les fibres sont des
threads plus légers, qui peuvent changer de contexte sans quitter le mode utilisateur.
Après activation de ce mode, SQLOS mappe ses worker threads à des fibres et non
plus à des threads Windows. Passer du mode thread au mode fibre se fait en changeant
l’option de serveur « lightweight pooling », comme ceci :
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
EXEC sp_configure 'lightweight pooling', 1
RECONFIGURE
EXEC sp_configure 'show advanced options', 0
RECONFIGURE
Ce changement n’est pas à faire à la légère, car il peut aussi avoir un effet négatif.
En tout cas, le gain a peu de chances d’être spectaculaire. Notez également que SQL
Mail n’est pas disponible en mode fibre (ce qui a peu d’impact, car vous l’avez certainement remplacé par l’outil Database Mail), ni le support des objets de code .NET.
Un compteur Thread\Context Switches/sec vous permet aussi d’entrer dans les
détails : quels threads sont beaucoup déplacés.
1. Comme nous l’explique Ken Henderson dans cet article de blog : http://blogs.msdn.com/
khen1234/archive/2005/11/07/489778.aspx
Chapitre 5. Analyse des performances
miné par l’option de configuration du serveur « max worker threads ». La valeur par
défaut de cette option est 0, qui correspond à une auto-configuration de SQL Server.
Cette valeur est optimale dans la grande majorité des cas. Si vous avez effectué une
mise à jour directe d’une instance SQL Server 2000 vers 2005, vérifiez que cette
valeur est bien à 0. En effet, en SQL Server 2000, la valeur par défaut était 255, et
elle demeure lors de la mise à jour. L’auto-configuration en SQL Server 2005 suit une
logique relative au nombre de processeurs, expliquée dans les BOL sous l’entrée
« max worker threads Option ». Pour connaître la valeur actuelle sur votre système :
SELECT max_workers_count
FROM sys.dm_os_sys_info
Il est hasardeux d’augmenter le nombre de worker threads, et en général inutile,
voire contre performant 1 . Cette option n’est pas une option intéressante pour augmenter les performances.
Donc, les changements de contexte sont coûteux, mais nécessaires. Des valeurs
comme 10 000 ou 15 000 sont normales. Une augmentation exagérée de context
switches devient un problème, car les processeurs passent trop de leur temps à changer de contexte. Dans ce cas, une augmentation du nombre de processeurs est à envisager. Dans un système en architecture SMP qui comporte beaucoup de processeurs,
où le nombre de changements de contexte est élevé de façon consistante, et où les
processeurs sont en utilisation presque maximum en permanence, vous pouvez
essayer de configurer SQL Server pour l’utilisation de fibres. Les fibres sont des
threads plus légers, qui peuvent changer de contexte sans quitter le mode utilisateur.
Après activation de ce mode, SQLOS mappe ses worker threads à des fibres et non
plus à des threads Windows. Passer du mode thread au mode fibre se fait en changeant
l’option de serveur « lightweight pooling », comme ceci :
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
EXEC sp_configure 'lightweight pooling', 1
RECONFIGURE
EXEC sp_configure 'show advanced options', 0
RECONFIGURE
Ce changement n’est pas à faire à la légère, car il peut aussi avoir un effet négatif.
En tout cas, le gain a peu de chances d’être spectaculaire. Notez également que SQL
Mail n’est pas disponible en mode fibre (ce qui a peu d’impact, car vous l’avez certainement remplacé par l’outil Database Mail), ni le support des objets de code .NET.
Un compteur Thread\Context Switches/sec vous permet aussi d’entrer dans les
détails : quels threads sont beaucoup déplacés.
1. Comme nous l’explique Ken Henderson dans cet article de blog : http://blogs.msdn.com/
khen1234/archive/2005/11/07/489778.aspx