Connaissances actuelles sur SQL Server et Hyperthreading?

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.

Dans SQLOS, un planificateur est créé pour chaque processeur logique que SQL Server voit. Avec l'hyperthreading activé, cela équivaut à doubler les planificateurs. L'un des objectifs de SQLOS est de minimiser et d'empêcher le changement de contexte de se produire, c'est pourquoi un seul planificateur est créé pour chaque processeur logique. Une fois que SQLOS crée les planificateurs, le nombre total de travailleurs est divisé entre les planificateurs. Le SQLOS implémente une forme d'ordonnancement coopératif en ce que les ouvriers produisent l'ordonnanceur car il nécessite des ressources indisponibles, ou atteint son quantum d'exécution permettant à d'autres ouvriers de s'exécuter sur l'ordonnanceur. Cela permet de maintenir le changement de contexte au minimum car le planificateur effectue le travail et ils sont liés un pour un.

Comprendre ce contexte, l'hyperthreading fonctionne quelque peu à l'opposé de la façon dont SQLOS est spécifiquement conçu pour fonctionner. Plus précisément, le parallélisme peut être problématique avec l'hyperthreading et peut entraîner des attentes CXPACKET élevées car SQLOS peut essayer d'exécuter une requête sur DOP 8 sur ce qui est en réalité un système DOP 4. Si votre utilisation du processeur est faible, vous ne le remarquerez peut-être pas, mais plus votre utilisation du processeur augmente, plus cela pourrait devenir problématique. J'ai récemment eu une discussion sur Twitter à ce sujet, et le consensus était "Cela dépend" de savoir si cela aiderait ou nuirait.

Si vous avez beaucoup d'attentes de signal sur votre serveur, mais vous avez une faible utilisation du processeur, vous pouvez voir l'avantage d'activer l'hyperthreading qui doublera vos planificateurs internes et répartira davantage les travailleurs, ce qui signifie qu'ils n'attendront pas pour s'exécuter dans la file d'attente exécutable aussi long. Cependant, si votre charge de travail utilise fortement le parallélisme, vous obtenez de lourdes attentes CXPACKET dans sys.dm_os_wait_stats, vous pouvez envisager de désactiver l'hyperthreading pour voir si cela réduit vos attentes.

En fait, l'hyperthreading n'a pas disparu, les nouvelles puces à quatre cœurs Nehalem d'Intel sont dotées d'hyperthreading. Quant à savoir si c'est recommandé ou non, "cela dépend" comme toujours, chaque situation est probablement différente.

Il est peu probable que HT soit la cause première de tout problème de performances, mais sans plus de détails, il est difficile de dire ce qui est. Effectuez des sessions perfmon, avec des taux d'échantillonnage assez longs, comme une fois toutes les 30 à 60 secondes, et avec un processeur, la longueur de la file d'attente sur les disques de données et de journaux, l'espérance de vie des pages est une bonne mesure pour savoir si vous avez suffisamment de mémoire. Si vous avez régulièrement plus de 80% de CPU, ou si vos files d'attente de disque sont à trois chiffres, vous avez trouvé votre problème.

SQL Server 2000 sur un HP DL360 G3:

J'ai exécuté un rapport six fois et j'ai jeté la fuite initiale et enregistré les cinq derniers. J'ai ensuite redémarré la base de données et réactivé l'hyperthreading. J'ai exécuté le rapport six fois de plus, en conservant les données des cinq dernières analyses.

Observations:

• La désactivation de l'hyperthreading ne coûte pas 2x en utilisation CPU apparente, seulement environ 1,5x.
• La désactivation de l'hyperthreading accélère l'exécution d'un rapport aléatoire de longue durée de 5,2% (en moyenne).

Exécutions répétées du rapport:

Avec hyperthreading: 20,95%, 21,1%, 21,9%, 20,8%, 20,5%
Temps d'exécution en ms: 20282, 21141, 20188, 22297, 25282. Moyenne 21838

Sans hyperthreading: 29,4%, 28,2%, 29,1%, 28,2%, 27,1%
Temps d'exécution en ms: 20125, 20156, 19937, 21656, 21656. Moyenne 20706