Zusammenfassung
Microsoft SQL Server 2005 verwendet den hochauflösenden CPU-Indikator, um Funktionen für das Timing im Mikrosekundenbereich bereitzustellen. Eine Mikrosekunde ist ein Millionstel einer Sekunde (oder ein Tausendstel einer Millisekunde). Die Zeitwerte für SQL Server können jedoch falsch sein, wenn Sie Technologien verwenden, die die CPU-Frequenzen ändern. Dieses Problem kann beispielsweise auftreten, wenn Sie eine der folgenden Technologien verwenden:
- CPU-Stepping
- AMD Cool'n'Quiet-Technologie
- Verschiedene Energieschemata
Dieser Artikel enthält Methoden und zusätzliche Informationen, die Ihnen helfen, dieses Problem zu umgehen.
Symptome
Wenn Sie die Anweisung SET STATISTICS TIME verwenden, um die Ausführungs-, Analyse- und Kompilierungszeiten des Servers anzuzeigen, erhalten Sie möglicherweise falsche Werte. Sie werden beispielsweise feststellen, dass die verstrichene Zeit der SQL Server Ausführungszeit viel länger ist als die CPU-Zeit. Dieses Problem kann sich auf die Genauigkeit der Leistungsoptimierung auswirken. Dieses Problem tritt auf, wenn Sie eine der im Abschnitt "Zusammenfassung" aufgeführten Technologien auf dem Server verwenden.
Ursache
Dieses Problem tritt auf, weil CPU-Frequenzen geändert werden, wenn Sie diese Technologien verwenden. SQL Server 2005 verwendet den hochauflösenden CPU-Indikator, um Zeitfunktionen im Mikrosekundenbereich bereitzustellen. Wenn die CPU-Frequenzen geändert werden, um Energie zu sparen und die Wärmeabgabe zu reduzieren, kann die berechnete Dauer falsch sein.
Lösung
Informationen zum Service Pack
Um dieses Problem zu beheben, besorgen Sie sich das neueste Service Pack für SQL Server 2005. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
913089 So erhalten Sie das neueste Service Pack für SQL Server 2005
Hinweis: In SQL Server 2005 Service Pack 3 und neueren Service Packs wird der Prozessorzeitstempel nicht verwendet. Diese Versionen von SQL Server 2005 verwenden einen zuverlässigeren Zeitgeber, der eine maximale Genauigkeit von 1 Millisekunde hat.
Status
Dieses Problem wurde erstmals in SQL Server 2005 Service Pack 3 behoben.
Problemumgehung
SQL Server 2005 benötigt bekannte und stabile Datenpunkte, um eine genaue Leistungsoptimierung durchzuführen. Wenn dynamische CPU-Frequenzanpassungen auf dem Computer aktiviert sind, können Sie sie deaktivieren, damit die CPUs eine konstante Frequenzrate beibehalten, bevor Sie mit der Überwachung und Optimierung der Leistung von SQL Server beginnen. Gehen Sie hierzu folgendermaßen vor.
Konfigurieren Sie das Energieschema auf dem Computer so, dass die CPUs auf der maximalen Frequenz bleiben
Führen Sie hierzu die folgenden Schritte aus:
Klicken Sie auf Start, klicken Sie auf Ausführen, geben Sie Powercfg.cpl ein, und klicken Sie dann auf OK.
Klicken Sie im Dialogfeld Eigenschaften der Energieoptionen in der Liste Energieschemas auf Always On.
Klicken Sie auf OK.
Es kann eine Abweichung auftreten. Eine Abweichung ist eine Abweichung zwischen CPU-Frequenzwerten. Weitere Informationen finden Sie im Abschnitt "Abweichungen". In diesem Fall müssen Sie Microsoft Windows neu starten, um die Frequenzen aller CPUs nach dem Ändern des Energieschemas neu zu synchronisieren.
Wenn Sie den Computer nicht neu starten können, aktivieren Sie die SQL Server-Prozessoraffinität, um zu verhindern, dass SQL Server-Arbeitsthreads zwischen CPUs verschoben werden. Wenn Sie dies tun, müssen Sie den Computer nicht neu starten, auch wenn eine Abweichung zwischen den CPU-Frequenzwerten auftritt. Um die Prozessoraffinität von SQL Server für alle CPUs auf dem Server zu aktivieren, müssen Sie je nach Anzahl der logischen Prozessoren auf dem Server eine andere Maske verwenden.
In der folgenden Tabelle sind Beispielszenarien aufgeführt.
| CPU-Nummer | Anweisungen zum Aktivieren der Prozessoraffinität |
|---|---|
| 02 CPUs | exec sp_configure "affinity mask", 0x00000003 GO Neu konfigurieren GO |
| 04 CPUs | exec sp_configure "affinity mask", 0x0000000F GO Neu konfigurieren GO |
| 08 CPUs | exec sp_configure "Affinity Mask", 0x000000FF GO Neu konfigurieren GO |
| 16 CPUs | exec sp_configure "affinity mask", 0x0000FFFF GO Neu konfigurieren GO |
| 32 CPUs | exec sp_configure "affinity mask", 0xFFFFFFFF GO Neu konfigurieren GO |
Hinweis: Möglicherweise reicht es nicht aus, um die Funktionen zur Variation der CPU-Frequenz auf BIOS-Ebene zu deaktivieren. Verschiedene Hilfsprogramme von Drittanbietern können die CPU-Frequenzen ändern. Einige Implementierungen aktivieren Frequenzanpassungen auch dann, wenn sich die CPUs in den Einstellungen für maximale Leistung befinden. In diesem Fall müssen Sie diese Hilfsprogramme von Drittanbietern deaktivieren, wenn Sie eine Leistungsoptimierung in SQL Server 2005 durchführen.
Verwenden von Hilfsprogrammen und Treibern von Drittanbietern zum Synchronisieren von CPU-Frequenzen und CPU-Taktzählern
In seltenen Fällen erfordert ein System möglicherweise ein Update vom Hersteller, um Probleme mit der CPU-Frequenz zu beheben. Es wird empfohlen, das System auf die neuesten BIOS-, Microcode- und Firmwareupdates zu überprüfen, wenn Sie vermuten, dass das System ein Problem hat.
Weitere Informationen
Microsoft SQL Server 2000 und frühere Versionen von SQL Server verwenden die Windows-Timing-Mechanismen. Die Timing-Mechanismen verwenden Millisekunden-Genauigkeitswerte. In der Regel liegt diese Genauigkeit zwischen 10 und 15 ms. Die Genauigkeit kann jedoch bis zu 55 ms betragen. SQL Server-Abfragen werden häufig innerhalb von Zeitspannen im einstelligen Millisekunden- oder Mikrosekundenbereich abgeschlossen. Diese Präzision erfordert einen hochauflösenden Timer. Daher melden diese Versionen von SQL Server die Dauer einiger Abfragen als 0 ms. Daher ist es schwierig, die Leistung von SQL Server in früheren Versionen von SQL Server zu überwachen und zu optimieren.
SQL Server 2005 verbessert die Genauigkeit, indem der hochauflösende CPU-Indikator verwendet wird, um Zeitfunktionen im Mikrosekundenbereich bereitzustellen. Wenn Sie die Technologien verwenden, die im Abschnitt "Zusammenfassung" aufgeführt sind, sind die gemeldeten Timing-Werte möglicherweise falsch.
Dieses Problem kann sich auf die folgenden Objekte und Features auswirken:
Ablaufverfolgungsereignisse:
Das Attention-Ereignis
Ereignisse im Knoten "Gespeicherte Prozeduren"
Ereignisse im TSQL-Knoten
Ereignisse im Objektknoten
Ereignisse im Transaktionsknoten
Dynamische Verwaltungssichten:
sys.dm_exec_query_stats
sys.dm_exec_requests
sys.dm_exec_sessions
sys.dm_io_pending_io_requests
sys.dm_os_ring_buffers
sys.dm_os_sys_info
sys.dm_io_virtual_file_stats
sys.dm_os_wait_stats
Die SET STATISTICS TIME-Anweisung
Systemtabelle "sysprocesses"
Nach der Installation von SQL Server 2005 Service Pack 2 (SP2) protokolliert SQL Server eine Fehlermeldung im Fehlerprotokoll, wenn SQL Server erkennt, dass die Timer mit hoher Auflösung zwischen den CPUs nicht synchronisiert sind. Die Fehlermeldung weist darauf hin, dass die Leistungszeitangaben möglicherweise nicht genau sind und Benutzer Leistungsdaten mit Vorsicht verwenden sollten.
Der Text der Fehlermeldung ähnelt einer der folgenden Fehlermeldungen:
Fehlermeldung 1
Hinweis
Der Zeitstempelzähler der CPU auf Scheduler-ID 2 ist nicht mit anderen CPUs synchronisiert.
Fehlermeldung 2
Hinweis
Die CPU-Zeitstempelhäufigkeit wurde von 191469 auf 1794177 Ticks pro Millisekunde geändert. Die neue Frequenz wird verwendet
SQL Server verwendet die RDTSC-Anweisung (Real Time Stamp Counter), um die Anzahl der 64-Bit-CPU-Ticks zu ermitteln. Sie können diesen Wert durch die CPU-Frequenz dividieren, um den Wert in Millisekundenwerte umzuwandeln. Timing-Variationen können auftreten, wenn sich die CPU-Frequenz ändert oder Drift auftritt.
CPU-Stepping
CPU-Stepping ist definiert als eine absichtliche Änderung der CPU-Frequenz. CPU-Stepping kann auch als Intel SpeedStep-Technologie oder AMD PowerNow bezeichnet werden! Technologie. Wenn CPU-Stepping auftritt, kann die CPU-Geschwindigkeit in Schritten von nur 50 MHz erhöht oder verringert werden, um Energie zu sparen und die Wärmeabgabe zu reduzieren. CPUs, die sich innerhalb desselben NUMA-Knotens (Non-Uniform Memory Access) befinden, passen Frequenzen nicht unabhängig voneinander an.
Die folgende Tabelle zeigt, wie sich CPU-Stepping-Änderungen auf Timing-Berechnungen auswirken können.
| Aktion | RDTSC-Ticks | Ticks pro Millisekunde (Häufigkeit) | Enduhrzeit |
|---|---|---|---|
| Batch starten | 1 | 200 | 0 |
| Frequenz nach unten | 200 | 100 | 1 ms |
| Batch beenden | 500 | 3 ms | |
| SUMMEN | 500 | 4 ms |
SQL Server erfasst die RDTSC-Ticks sowohl am Start als auch am Ende der RDTSC-Ticks. Anschließend dividiert SQL Server die Ticks durch den Häufigkeitswert.
In diesem Beispiel werden die folgenden Timing-Berechnungen durchgeführt, wenn Sie einen Frequenzwert von 200 oder 100 verwenden:
Frequenz 200: 500/200 = 2,5 ms
Frequenz 100: 500/100 = 5 ms
Keine der Timing-Berechnungen entspricht der tatsächlichen Wanduhrzeit von 4 ms.
Wenn diese Berechnung in einem RPC:Completed-Ablaufverfolgungsereignis verwendet wird, werden die Datenspalten "Dauer" und "Endzeit" falsch gemeldet. Das RPC:Completed-Ereignis erfasst die Startuhrzeit und die Anzahl der CPU-Ticks. Um eine höhere Auflösung zu erhalten, als Windows in SQL Server 2005 mitgeliefert wird, werden die Datenspalten "Dauer" und "Endzeit" in einer SQL Server-Ablaufverfolgung mithilfe der verstrichenen CPU-Taktanzahl berechnet. Die Endzeitspalte wird berechnet, indem der Startzeitspalte die Spalte "Dauer" hinzugefügt wird. In diesem Beispiel wird die Endzeitspalte berechnet, indem fälschlicherweise entweder 2,5 ms oder 5 ms zur Startzeit addiert werden.
Abweichungen
Drift ist eine Divergenz in den CPU-Taktwerten. Systeme mit mehreren CPUs können für denselben Zeitpunkt unterschiedliche CPU-Taktwerte erzeugen. Obwohl es nicht üblich ist, kann es bei CPUs im Laufe der Zeit zu einer Takttrennung kommen.
Das folgende Beispiel zeigt, wie sich Abweichungsänderungen auf das Ergebnis der Datenspalte "Dauer" in einer SQL Server-Ablaufverfolgung auswirken können. Im Beispiel wird davon ausgegangen, dass die CPU-Frequenz konstant bei 200 Ticks pro Millisekunde bleibt. Die folgende Tabelle veranschaulicht die Ereignisse in diesem Szenario.
| Aktion | Geplante Windows-CPU | CPU 1 RDTSC | CPU 2 RDTSC | Enduhrzeit |
|---|---|---|---|---|
| Batch starten | 1 | 100 | 1100 | 0 |
| Batch beenden | 2 | 900 | 1900 | 4 ms |
| SUMMEN | 4 ms |
SQL Server erfasst die RDTSC-Ticks sowohl am Startpunkt als auch am Endpunkt. Anschließend teilt SQL Server die RDTSC-Ticks durch den Häufigkeitswert. In diesem Beispiel hat Windows den SQL Server Arbeitsthread auf zwei verschiedenen CPUs geplant. Der SQL Server Arbeitsthread, der den Batch verarbeitet, wurde zuerst auf der ersten CPU (CPU 1) ausgeführt.
Die Batchausführung wurde jedoch irgendwann unterbrochen, und SQL Server hat die Batchausführung an die ausstehende Warteschlange gesendet. Als SQL Server den SQL Server Arbeitsthread, der diesen Batch verarbeitet, erneut in die ausführbare Warteschlange gesendet hat, hat Windows den Thread zur Ausführung auf der zweiten CPU (CPU 2) verteilt. Der SQL Server-Arbeitsthread wurde bei der Ausführung auf CPU 2 abgeschlossen. Aufgrund von CPU-Drift betrug der von CPU 2 erfasste End-Tick-Wert 1900 statt 900. Sie können dieses Verhalten vermeiden, wenn Sie die Prozessoraffinität von SQL Server aktivieren.
In diesem Beispiel kommen folgende Timing-Berechnungen zum Einsatz:
- Der falsche, aber gemeldete Wert: (1900 – 100 = 1800) / 200 = 9 ms
- Korrekter Wert: (900 – 100 = 800) / 200 = 4 ms
Der Wert in der Spalte "Dauer" für das Ereignis RPC:Completed würde mit 9 ms statt mit 4 ms gemeldet werden. Dieses Ergebnis ist mehr als doppelt so hoch wie der korrekte Wert von 4 ms.
SQL Server 2005 wird zu Abweichungswarnungen hinzugefügt, um anzuzeigen, dass die oben genannten Leistungsausgaben möglicherweise nicht zuverlässig sind. In einigen nicht aufgedeckten Situationen kann SQL Server 2005 SP2 Warnmeldungen zu den folgenden Informationen melden:
- Warnmeldungen zu falschen Abweichungen
- Die Abweichung kann sich auf mehrere zehn Millisekunden belaufen, ohne dass dies zu einem spürbaren Systemeffekt kommt
Sie müssen vorsichtig sein, wenn Sie die leistungsbezogenen Ausgaben auswerten und wenn Sie die leistungsbezogenen Ausgaben mit den Wanduhr-Timings vergleichen. Wenn es keine Anzeichen für andere Leistungsprobleme gibt, können Sie die Abweichungswarnungen in der Regel ignorieren. Beispielsweise können Sie die Abweichungswarnungen in der Regel in den folgenden Situationen ignorieren:
- Prozesse laufen wie erwartet.
- SQL Server-Abfragen werden nicht in seltsamen Dauermustern ausgeführt.
- Sie sehen keine Anzeichen für andere Engpässe.
Bevor Sie jedoch die Abweichungswarnungen ignorieren, sollten Sie sich an den Hersteller wenden, um sicherzustellen, dass keine RDTSC-Probleme bekannt sind.
Sie können das Ablaufverfolgungsflag 8033 (–T8033) verwenden, um zum Berichterstellungsverhalten in der ursprünglichen endgültigen Version von SQL Server 2005 und in SQL Server 2005 SP1 zurückzukehren. Die ursprüngliche endgültige Produktversion von SQL Server 2005 und SQL Server 2005 SP1 meldet keine Abweichungswarnungen. Wenn Sie die ursprüngliche Release-Version von SQL Server 2005 oder SQL Server 2005 SP1 ohne Probleme ausführen, können Sie die Meldungen in der Regel ignorieren.
Warum funktioniert die Anweisung "WAITFOR DELAY" ordnungsgemäß? Was ist mit periodischen Systemprozessen?
Timeout-Mechanismen werden durch das hochauflösende Design nicht beeinflusst. SQL Server verwendet den Timer mit hoher Auflösung nicht für zeitgeberbasierte Aktivitäten. Einige Timeout-Aktivitäten basieren auf dem Timer mit reduzierter Auflösung, der die GetTickCount-Funktion verwendet. Zu diesen Timeout-Aktivitäten gehören das Sperrtimeout, die WAITFOR DELAY-Anweisung und die Deadlock-Erkennung.
Weitere Informationen finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:
938448 Bei einem Windows Server 2003-basierten Server kann es zu Zeitstempelzählerabweichungen kommen, wenn der Server Dual-Core-AMD Opteron-Prozessoren oder AMD Opteron-Multiprozessoren verwendet
895980 Programme, die die QueryPerformanceCounter-Funktion verwenden, funktionieren unter Windows Server 2003 und Windows XP möglicherweise schlecht
Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.