Zusammenfassung
Microsoft SQL Server 2005 verwendet den hochauflösenden CPU-Zähler, um Zeitsteuerungsfunktionen in Mikrosekunden bereitzustellen. Eine Mikrosekunde ist eine Millionstelsekunde (oder ein Tausendstel einer Millisekunde). Allerdings können SQL Server Zeitsteuerungswerte falsch sein, wenn Sie Technologien verwenden, die die CPU-Frequenzen ändern. Dieses Problem kann beispielsweise auftreten, wenn Sie eine der folgenden Technologien verwenden:
- CPU-Schrittweises Ausführen
- AMD Cool'n'Quiet-Technologie
- Verschiedene Energieschemas
Dieser Artikel enthält Methoden und zusätzliche Informationen, die Ihnen helfen, dieses Problem zu umgehen.
Symptome
Wenn Sie die SET STATISTICS TIME-Anweisung verwenden, um serverausführungs-, analyse- und kompilierungszeiten anzuzeigen, erhalten Sie möglicherweise falsche Werte. Beispielsweise können Sie feststellen, dass die verstrichene Zeit der SQL Server Ausführungszeit viel höher ist als die CPU-Zeit. Dieses Problem kann sich auf die Genauigkeit der Leistungsoptimierung auswirken. Dieses Problem tritt auf, wenn Sie eine der Technologien verwenden, die im Abschnitt "Zusammenfassung" auf dem Server aufgeführt sind.
Ursache
Dieses Problem tritt auf, weil die CPU-Frequenzen geändert werden, wenn Sie diese Technologien verwenden. SQL Server 2005 verwendet den hochauflösenden CPU-Zähler, um Zeitsteuerungsfunktionen in Mikrosekunden bereitzustellen. Wenn CPU-Frequenzen geändert werden, um Energie zu sparen und die Wärmeausgabe zu reduzieren, kann die berechnete Dauer falsch sein.
Lösung
Service Pack-Informationen
Um dieses Problem zu beheben, rufen Sie das neueste Service Pack für SQL Server 2005 ab. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base:
913089 Abrufen des neuesten Service Packs für SQL Server 2005
Hinweis In SQL Server 2005 Service Pack 3 und späteren Service Packs wird der Prozessorzeitstempel nicht verwendet. Diese Versionen von SQL Server 2005 verwenden einen zuverlässigeren Timer mit einer maximalen Genauigkeit von 1 Millisekunde.
Status
Dieses Problem wurde erstmals in SQL Server 2005 Service Pack 3 behoben.
Problemumgehung
SQL Server 2005 erfordert 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 SQL Server Leistung beginnen. Gehen Sie hierzu folgendermaßen vor.
Konfigurieren Sie das Energieschema auf dem Computer, um zu erzwingen, dass die CPUs bei maximaler Häufigkeit verbleiben.
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 Energieoptionen-Eigenschaften in der Liste Energieschemas auf Always On.
Klicken Sie auf OK.
Es kann zu einer Abweichung kommen. Eine Abweichung ist eine Abweichung zwischen CPU-Frequenzwerten. Weitere Informationen finden Sie im Abschnitt "Drift". In diesem Fall müssen Sie Microsoft Windows neu starten, um die Frequenzen aller CPUs neu zu synchronisieren, nachdem Sie das Energieschema geändert haben.
Wenn Sie den Computer nicht neu starten können, aktivieren Sie 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-Häufigkeitswerten auftritt. Um SQL Server Prozessoraffinität 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 Konfigurieren GO |
| 04 CPUs | exec sp_configure "Affinity Mask", 0x0000000F GO Konfigurieren GO |
| 08 CPUs | exec sp_configure "Affinity Mask", 0x000000FF GO Konfigurieren GO |
| 16 CPUs | exec sp_configure "Affinity Mask", 0x0000FFFF GO Konfigurieren GO |
| 32 CPUs | exec sp_configure "Affinity Mask", 0xFFFFFFFF GO Konfigurieren GO |
Hinweis Möglicherweise reicht es nicht aus, um CPU-Frequenzvariationsfeatures auf BIOS-Ebene zu deaktivieren. Verschiedene Hilfsprogramme von Drittanbietern können CPU-Frequenzen ändern. Einige Implementierungen ermöglichen Frequenzanpassungen, auch wenn sich die CPUs unter den Einstellungen für das maximale Energieschema befinden. In diesem Fall müssen Sie diese Hilfsprogramme von Drittanbietern deaktivieren, wenn Sie die 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-Häufigkeit zu beheben. Es ist eine bewährte Methode, das System auf die neuesten BIOS-, Microcode- und Firmwareupdates zu überprüfen, wenn Sie vermuten, dass das System möglicherweise ein Problem hat.
Weitere Informationen
Microsoft SQL Server 2000 und frühere Versionen von SQL Server verwenden die Windows-Zeitsteuerungsmechanismen. Die Zeitsteuerungsmechanismen verwenden Millisekundengenauigkeitswerte. In der Regel beträgt diese Genauigkeit 10 bis 15 ms. Die Genauigkeit kann jedoch bis zu 55 ms betragen. SQL Server Abfragen werden häufig innerhalb eines einstelligen Millisekunden- oder Mikrosekundenzeitbereichs abgeschlossen. Diese Genauigkeit erfordert einen hochauflösenden Timer. Daher geben diese Versionen von SQL Server die Dauer einiger Abfragen als 0 ms an. Daher ist es schwierig, die Leistung zu überwachen und SQL Server Leistung in früheren Versionen von SQL Server zu optimieren.
SQL Server 2005 verbessert die Genauigkeit, indem der hochauflösende CPU-Zähler verwendet wird, um Zeitsteuerungsfunktionen in Mikrosekunden bereitzustellen. Wenn Sie die im Abschnitt "Zusammenfassung" aufgeführten Technologien verwenden, sind die gemeldeten Zeitsteuerungswerte 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 Knoten Objekte
Ereignisse im Knoten Transaktionen
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
Die systemtabelle sysprocesses
Nachdem Sie SQL Server 2005 Service Pack 2 (SP2) installiert haben, protokolliert SQL Server eine Fehlermeldung im Fehlerprotokoll, wenn SQL Server erkennt, dass die Zeitgeber mit hoher Auflösung zwischen den CPUs nicht synchron sind. Die Fehlermeldung weist darauf hin, dass Leistungsdauern möglicherweise nicht korrekt 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 Planer-ID 2 wird nicht mit anderen CPUs synchronisiert.
Fehlermeldung 2
Hinweis
Die CPU-Zeitstempelhäufigkeit hat sich von 191469 in 1794177 Ticks pro Millisekunde geändert. Die neue Häufigkeit wird verwendet.
SQL Server verwendet die RDTSC-Anweisung (Real Time Stamp Counter), um die 64-Bit-CPU-Taktanzahl zu erhalten. Sie können diesen Wert durch die CPU-Häufigkeit dividieren, um den Wert in Millisekundenwerte zu konvertieren. Zeitliche Abweichungen können auftreten, wenn sich die CPU-Frequenz ändert oder eine Abweichung auftritt.
CPU-Schrittweises Ausführen
CPU-Schrittweises Ausführen ist als eine absichtliche Änderung der CPU-Frequenz definiert. CPU-Step kann auch als Intel SpeedStep-Technologie oder AMD PowerNow! Technologie. Wenn ein CPU-Schritt ausgeführt wird, kann die CPU-Geschwindigkeit in Schritten von bis zu 50 MHz erhöht oder verringert werden, um Energie zu sparen und die Wärmeausgabe zu reduzieren. CPUs, die sich innerhalb desselben NUMA-Knotens (Non-Uniform Memory Access) befinden, passen die Frequenzen nicht unabhängig an.
In der folgenden Tabelle wird veranschaulicht, wie sich Änderungen an der CPU-Schrittweisenausführung auf die Zeitsteuerungsberechnungen auswirken können.
| Aktion | RDTSC Ticks | Takte pro Millisekunde (Häufigkeit) | Wanduhrzeit |
|---|---|---|---|
| Batch starten | 1 | 200 | 0 |
| Häufigkeitsschritt nach unten | 200 | 100 | 1 ms |
| Batch beenden | 500 | 3 ms | |
| SUMMEN | 500 | 4 ms |
SQL Server erfasst die RDTSC-Ticks sowohl am RdTSC-Anfang als auch am Ende. Anschließend dividiert SQL Server die Ticks durch den Häufigkeitswert.
In diesem Beispiel werden die folgenden Zeitsteuerungsberechnungen ausgeführt, wenn Sie einen Häufigkeitswert von 200 oder 100 verwenden:
Frequenz 200: 500/200 = 2,5 ms
Frequenz 100: 500/100 = 5 ms
Keine der Zeitsteuerungsberechnungen entspricht der tatsächlichen Wanduhrzeit von 4 ms.
Wenn diese Berechnung in einem RPC:Completed-Ablaufverfolgungsereignis verwendet wird, werden die Datenspalten für Dauer und Endzeit falsch gemeldet. Das RPC:Completed-Ereignis erfasst die Startuhrzeit und die CPU-Taktanzahl. Um eine höhere Auflösung als windows in SQL Server 2005 zu erhalten, werden die Datenspalten für Dauer und Endzeit in einer SQL Server Ablaufverfolgung anhand der anzahl verstrichener CPU-Takte berechnet. Die Endzeitspalte wird berechnet, indem die Spalte duration zur Startzeit hinzugefügt wird. In diesem Beispiel wird die Endzeitspalte berechnet, indem der Startzeit fälschlicherweise 2,5 ms oder 5 ms hinzugefügt werden.
Drift
Drift ist eine Divergenz der CPU-Taktwerte. Systeme mit mehreren CPUs können unterschiedliche CPU-Taktwerte für denselben Zeitpunkt erzeugen. Obwohl dies nicht üblich ist, kann es bei CPUs im Laufe der Zeit zu einer Trennung der Uhr kommt.
Im folgenden Beispiel wird veranschaulicht, wie sich Abweichungsänderungen auf das Ergebnis der Datenspalte "duration" in einer SQL Server Ablaufverfolgung auswirken können. Im Beispiel wird davon ausgegangen, dass die CPU-Frequenz bei 200 Ticks pro Millisekunde konstant bleibt. Die folgende Tabelle veranschaulicht die Ereignisse in diesem Szenario.
| Aktion | Geplante WINDOWS-CPU | CPU 1 RDTSC | CPU 2 RDTSC | Wanduhrzeit |
|---|---|---|---|---|
| Batch starten | 1 | 100 | 1100 | 0 |
| Batch beenden | 2 | 900 | 1900 | 4 ms |
| SUMMEN | 4 ms |
SQL Server erfasst die RDTSC-Ticks sowohl an den Start- als auch an den Endpunkten. Anschließend dividiert SQL Server die RDTSC-Ticks durch den Häufigkeitswert. In diesem Beispiel hat Windows den SQL Server-Arbeitsthreads auf zwei verschiedenen CPUs geplant. Der SQL Server Workerthread, der den Batch verwendet, wurde zuerst auf der ersten CPU (CPU 1) ausgeführt.
Die Batchausführung wurde jedoch irgendwann unterbrochen, und SQL Server die Batchausführung an die ausstehende Warteschlange gesendet. Wenn SQL Server den SQL Server Arbeitsthread, der diesen Batch verarbeitet, erneut an die ausführende Warteschlange gesendet hat, hat Windows den Thread so verteilt, dass er auf der zweiten CPU (CPU 2) ausgeführt wird. Der SQL Server Arbeitsthreads wurde auf CPU 2 ausgeführt. Aufgrund der CPU-Abweichung war der end-Tick-Wert, der von CPU 2 erfasst wurde, 1900 statt 900. Sie können dieses Verhalten vermeiden, wenn Sie SQL Server Prozessoraffinität aktivieren.
In diesem Beispiel werden die folgenden Zeitsteuerungsberechnungen verwendet:
- Der falsche, aber gemeldete Wert: (1900 – 100 = 1800) / 200 = 9 ms
- Richtiger Wert: (900 – 100 = 800) / 200 = 4 ms
Der Wert der Dauerspalte für das RPC:Completed-Ereignis würde als 9 ms anstelle von 4 ms gemeldet. Dieses Ergebnis ist mehr als doppelt so viel wie der richtige Wert von 4 ms.
Abweichungswarnungen werden SQL Server 2005 hinzugefügt, um darauf hinzuweisen, dass die oben erwähnten Leistungsausgaben möglicherweise nicht zuverlässig sind. In einigen nicht entdeckten Situationen kann SQL Server 2005 SP2 Warnmeldungen zu folgenden Themen melden:
- Warnungen zu falscher Abweichung
- Drift kann zu Dutzenden von Millisekunden werden, ohne einen spürbaren Systemeffekt zu verursachen
Sie müssen vorsichtig sein, wenn Sie die leistungsbezogenen Ausgaben auswerten und die leistungsbezogenen Ausgaben mit den Anzeigedauern der Wanduhr vergleichen. Wenn keine Anzeichen für andere Leistungsprobleme vorliegen, können Sie die Abweichungswarnungen in der Regel ignorieren. Beispielsweise können Sie die Abweichungswarnungen in der Regel in den folgenden Situationen ignorieren:
- Prozesse werden erwartungsgemäß ausgeführt.
- SQL Server Abfragen werden nicht in ungewöhnlichen Dauermustern ausgeführt.
- Sie sehen keine Anzeichen für andere Engpässe.
Bevor Sie jedoch die Abweichungswarnungen ignorieren, empfehlen wir Ihnen, sich an Ihren Hersteller zu wenden, um sicherzustellen, dass keine bekannten RDTSC-Probleme vorliegen.
Sie können das Ablaufverfolgungsflag 8033 (–T8033) verwenden, um zum Berichtsverhalten in der ursprünglichen Version von SQL Server 2005 und in SQL Server 2005 SP1 zurückzukehren. Die ursprüngliche Version von SQL Server 2005 und SQL Server 2005 SP1 melden keine Abweichungswarnungen. Wenn Sie die ursprüngliche Releaseversion von SQL Server 2005 oder SQL Server 2005 SP1 problemlos ausführen, können Sie die Nachrichten in der Regel ignorieren.
Warum funktioniert die WAITFOR DELAY-Anweisung ordnungsgemäß? Was ist mit periodischen Systemprozessen?
Timeoutmechanismen sind vom hochauflösenden Design nicht betroffen. SQL Server verwendet den hochauflösenden Timer nicht für zeitgeberbasierte Aktivitäten. Einige Timeoutaktivitäten basieren auf dem Timer mit reduzierter Auflösung, der die GetTickCount-Funktion verwendet. Zu diesen Timeoutaktivitäten gehören Sperrtimeout, die WAITFOR DELAY-Anweisung und die Deadlockerkennung.
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 führen, wenn der Server AMD Opteron-Dual-Core-Prozessoren oder AMD Opteron-Multiprozessorprozessoren verwendet.
895980 Programme, die die QueryPerformanceCounter-Funktion verwenden, funktionieren in 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.