Aktuelle Erkenntnisse zu SQL Server und Hyperthreading?

In vielen Artikeln (siehe den ursprünglichen SQL 2000-Artikel von Slava Oks und das SQL 2005-Update von Kevin Kline ) wird empfohlen, das Hyperthreading auf SQL-Servern zu deaktivieren oder zumindest Ihre spezifische Arbeitslast zu testen, bevor Sie es auf Ihren Servern aktivieren.

Dieses Problem wird allmählich weniger relevant, da echte Multi-Core-Prozessoren Hyperthread-Prozessoren ersetzen. Wie ist die aktuelle Weisheit zu diesem Problem? Ändert sich dieser Rat bei SQL 2005 64-Bit, SQL 2008 oder Windows Server 2008?

Idealerweise sollte dies im Voraus in einer Staging-Umgebung getestet werden. Was ist jedoch mit Servern, die es bereits mit aktiviertem HT in die Produktion geschafft haben? Wie kann ich feststellen, ob Leistungsprobleme mit HT zusammenhängen? Gibt es eine bestimmte Kombination von Perfmon-Zählern, die mich in diese Richtung weisen könnten, im Gegensatz zu all den anderen Dingen, die ich normalerweise bei der Verbesserung der SQL-Leistung verfolge?

Bearbeiten : Dies ist besonders attraktiv , weil das Potenzial für eine auf der ganzen Linie Verbesserung für einige meiner High-CPU - Server, aber der Client gehen zu wollen , etwas Konkretes zu sehen , die mich identifizieren hilft , welche Server wirklich von deaktivieren Hyperthreading profitieren könnten. Natürlich wird die herkömmliche Fehlerbehebung bei der Leistung fortgesetzt, aber manchmal hilft ein bisschen.

In SQLOS wird für jeden logischen Prozessor, den SQL Server sieht, ein Scheduler erstellt. Wenn Hyperthreading aktiviert ist, bedeutet dies, dass die Scheduler verdoppelt werden. Ein Zweck von SQLOS besteht darin, das Auftreten von Kontextwechseln zu minimieren und zu verhindern, weshalb für jeden logischen Prozessor nur ein Scheduler erstellt wird. Sobald das SQLOS die Scheduler erstellt hat, wird die Gesamtzahl der Worker auf die Scheduler aufgeteilt. Das SQLOS implementiert eine Form der kooperativen Planung, indem die Worker den Scheduler ausgeben, da er nicht verfügbare Ressourcen benötigt, oder sein Ausführungsquantum erreicht, das es anderen Workern ermöglicht, auf dem Scheduler auszuführen. Dadurch wird die Kontextumschaltung auf ein Minimum beschränkt, da der Scheduler die Arbeit erledigt und sie eins zu eins gebunden sind.

Wenn man diesen Hintergrund versteht, funktioniert Hyperthreading etwas anders als SQLOS speziell für die Funktionsweise entwickelt wurde. Insbesondere kann Parallelität beim Hyperthreading problematisch sein und zu hohen CXPACKET-Wartezeiten führen, da SQLOS möglicherweise versucht, eine Abfrage bei DOP 8 auf einem DOP 4-System auszuführen. Wenn Ihre CPU-Auslastung niedrig ist, werden Sie es möglicherweise nicht bemerken, aber je höher Ihre CPU-Auslastung ist, desto problematischer kann es werden. Ich hatte kürzlich eine Diskussion auf Twitter darüber und der Konsens war "Es hängt davon ab", ob es helfen oder schaden würde oder nicht.

Wenn auf Ihrem Server viele Signalwartezeiten auftreten, die CPU-Auslastung jedoch gering ist, kann es von Vorteil sein, Hyperthreading zu aktivieren, wodurch Ihre internen Scheduler verdoppelt und die Worker stärker verteilt werden, sodass sie nicht auf die Ausführung in der ausführbaren Warteschlange warten müssen so lange. Wenn Ihre Workload jedoch stark von Parallelität profitiert, kommt es in sys.dm_os_wait_stats zu starken CXPACKET-Wartezeiten. Möglicherweise möchten Sie das Hyperthreading deaktivieren, um festzustellen, ob es Ihre Wartezeiten verringert.

Eigentlich ist das Hyperthreading nicht verschwunden, die neuen Nehalem Quad-Core-Chips von Intel haben das Hyperthreading. Ob es empfohlen wird oder nicht, "es kommt darauf an" wie immer, jede Situation ist wahrscheinlich anders.

Es ist unwahrscheinlich, dass HT die Hauptursache für Leistungsprobleme ist, aber ohne weitere Details ist es schwierig zu sagen, was es ist. Wenn Sie einige Perfmon-Sitzungen mit relativ langen Abtastraten durchführen, z. B. alle 30 bis 60 Sekunden, und die CPU, die Länge der Festplattenwarteschlange auf den Daten- und Protokolldatenträgern ermitteln, ist die Lebenserwartung der Seiten ein gutes Maß dafür, ob Sie über genügend Speicher verfügen. Wenn Sie konsistent über 80% der CPU verfügen oder die Festplattenwarteschlangen dreistellig sind, haben Sie Ihr Problem gefunden.

SQL Server 2000 auf einem HP DL360 G3:

Ich habe sechs Mal einen Bericht erstellt und den ersten Lauf weggeworfen und die letzten fünf aufgezeichnet. Ich habe dann die Datenbank erneut neu gestartet und Hyperthreading wieder aktiviert. Ich habe den Bericht noch sechs Mal ausgeführt und dabei die Daten der letzten fünf Läufe beibehalten.

Beobachtungen:

• Das Deaktivieren von Hyperthreading kostet bei der scheinbaren CPU-Auslastung nicht das Zweifache, sondern nur das 1,5-fache.
• Durch Deaktivieren von Hyperthreading wird ein zufälliger Bericht mit langer Laufzeit (im Durchschnitt) um 5,2% schneller ausgeführt.

Wiederholte Läufe des Berichts:

Mit Hyperthreading: 20,95%, 21,1%, 21,9%, 20,8%, 20,5%
Laufzeiten in ms: 20282, 21141, 20188, 22297, 25282. Durchschnitt 21838

Ohne Hyperthreading: 29,4%, 28,2%, 29,1%, 28,2%, 27,1%
Laufzeiten in ms: 20125, 20156, 19937, 21656, 21656. Durchschnitt 20706