39
3.1 Choix de l’architecture matérielle
SQL Server 2005, édition Entreprise – Le ramp-up est optimisé pour être plus rapide
sur les machines ayant beaucoup de mémoire, parce que les requêtes de pages uniques sont
converties en requêtes de 8 pages contiguës. En 2008 cette fonctionnalité n’est plus limitée à
l’édition entreprise.
3.1.4 Disques
Le choix des sous-systèmes disque est bien sûr important. Il est probable que vous
soyez de plus en plus dotés de SAN, où les performances sont gérées de façon moins
directe que pour des disques locaux, chaque vendeur fournit son outil de gestion.
Vous trouvez des conseils pour les SAN dans cette entrée de blog en trois parties :
http://blogs.msdn.com/sqlcat/archive/2005/10/11/479887.aspx.
Pour le reste, les règles sont simples : les disques doivent être rapides et profiter
d’un taux de transfert élevé. C’est moins important pour les disques qui hébergeront
les fichiers de données, si la taille des bases est inférieure à la mémoire vive. À ce
moment, la plupart des requêtes seront satisfaites par le cache de données (le buffer).
Autant que possible, choisissez du RAID 10 (ou 01) plutôt que du RAID 5, car les
performances en écriture du RAID 5 sont nettement plus faibles. Déplacez autant
que possible vos journaux de transactions sur des disques dédiés, ce qui permettra
une écriture séquentielle optimale. Dédiez le disque le plus rapide, de préférence un
disque local, à tempdb. Tout ce qui est dans tempdb est jetable : vous n’avez donc pas
besoin d’assurer une sécurité importante de ce disque. Un simple miroir pour éviter
les interruptions de service suffit.
Vous avez quelques outils à disposition pour mesure la performance de vos disques :
• IOMeter et SQLIO sont des outils de pur contrôle des performances (benchmarking) de disque en ligne de commande. Ils sont libres et téléchargeables sur
Sourceforge pour le premier, et sur le site de Microsoft pour le second. Ils vous
donnent les performances de vos disques. Vous trouvez des conseils d’utilisation
en consultant des entrées de blog et références :
– http://blogs.msdn.com/sqlcat/archive/2005/11/17/493944.aspx
– http://sqlblog.com/blogs/linchi_shea/archive/2007/02/21/parse-the-sqlio-exeoutput.aspx
– http://www.microsoft.com/whdc/device/storage/subsys_perf.mspx
• SQLIOSim est un outil de pur stress sur le disque, qui se fonde sur le même
code d’accès au disque que SQL Server (qui n’a pas besoin d’être installé),
pour mesurer la robustesse de votre stockage de masse. Plus d’information
dans l’entrée de base de connaissance Microsoft 231619 :
http://support.microsoft.com/kb/231619
Pression sur le disque
Le compteur de performances (voir section 5.3) à surveiller pour identifier une
contention sur les disques est PhysicalDisk: Avg. Disk Queue Length. Il indique la
taille de la file d’attente, c’est-à-dire les processus qui attendent la libération du
3.1 Choix de l’architecture matérielle
SQL Server 2005, édition Entreprise – Le ramp-up est optimisé pour être plus rapide
sur les machines ayant beaucoup de mémoire, parce que les requêtes de pages uniques sont
converties en requêtes de 8 pages contiguës. En 2008 cette fonctionnalité n’est plus limitée à
l’édition entreprise.
3.1.4 Disques
Le choix des sous-systèmes disque est bien sûr important. Il est probable que vous
soyez de plus en plus dotés de SAN, où les performances sont gérées de façon moins
directe que pour des disques locaux, chaque vendeur fournit son outil de gestion.
Vous trouvez des conseils pour les SAN dans cette entrée de blog en trois parties :
http://blogs.msdn.com/sqlcat/archive/2005/10/11/479887.aspx.
Pour le reste, les règles sont simples : les disques doivent être rapides et profiter
d’un taux de transfert élevé. C’est moins important pour les disques qui hébergeront
les fichiers de données, si la taille des bases est inférieure à la mémoire vive. À ce
moment, la plupart des requêtes seront satisfaites par le cache de données (le buffer).
Autant que possible, choisissez du RAID 10 (ou 01) plutôt que du RAID 5, car les
performances en écriture du RAID 5 sont nettement plus faibles. Déplacez autant
que possible vos journaux de transactions sur des disques dédiés, ce qui permettra
une écriture séquentielle optimale. Dédiez le disque le plus rapide, de préférence un
disque local, à tempdb. Tout ce qui est dans tempdb est jetable : vous n’avez donc pas
besoin d’assurer une sécurité importante de ce disque. Un simple miroir pour éviter
les interruptions de service suffit.
Vous avez quelques outils à disposition pour mesure la performance de vos disques :
• IOMeter et SQLIO sont des outils de pur contrôle des performances (benchmarking) de disque en ligne de commande. Ils sont libres et téléchargeables sur
Sourceforge pour le premier, et sur le site de Microsoft pour le second. Ils vous
donnent les performances de vos disques. Vous trouvez des conseils d’utilisation
en consultant des entrées de blog et références :
– http://blogs.msdn.com/sqlcat/archive/2005/11/17/493944.aspx
– http://sqlblog.com/blogs/linchi_shea/archive/2007/02/21/parse-the-sqlio-exeoutput.aspx
– http://www.microsoft.com/whdc/device/storage/subsys_perf.mspx
• SQLIOSim est un outil de pur stress sur le disque, qui se fonde sur le même
code d’accès au disque que SQL Server (qui n’a pas besoin d’être installé),
pour mesurer la robustesse de votre stockage de masse. Plus d’information
dans l’entrée de base de connaissance Microsoft 231619 :
http://support.microsoft.com/kb/231619
Pression sur le disque
Le compteur de performances (voir section 5.3) à surveiller pour identifier une
contention sur les disques est PhysicalDisk: Avg. Disk Queue Length. Il indique la
taille de la file d’attente, c’est-à-dire les processus qui attendent la libération du