De nombreux articles (voir l'article SQL 2000 original de Slava Oks et la mise à jour SQL 2005 de Kevin Kline ) recommandent de désactiver l'hyperthreading sur les serveurs SQL, ou au moins de tester votre charge de travail spécifique avant de l'activer sur vos serveurs.
Ce problème devient progressivement moins pertinent à mesure que les vrais processeurs multicœurs remplacent ceux hyperthreadés, mais quelle est la sagesse actuelle sur ce problème? Ce conseil change-t-il avec SQL 2005 64 bits, SQL 2008 ou Windows Server 2008?
Idéalement, cela devrait être testé à l'avance dans un environnement de transfert, mais qu'en est-il des serveurs qui ont déjà été mis en production avec HT activé? Comment savoir si les problèmes de performances que nous rencontrons peuvent être liés à HT? Existe-t-il une combinaison spécifique de compteurs perfmon qui pourrait m'orienter dans cette direction, par opposition à toutes les autres choses que je poursuis normalement lorsque je travaille sur l'amélioration des performances SQL?
Modifier : Ceci est particulièrement intéressant en raison du potentiel d'un dans tous les domaines d' amélioration pour certains de mes serveurs haut de cpu, mais le client va vouloir voir quelque chose de concret qui me permet d' identifier quels serveurs pourraient vraiment bénéficier de désactiver l' hyperthreading. Bien sûr, le dépannage des performances conventionnel est en cours, mais parfois un petit peu aide.