Database
 sql >> Datenbank >  >> RDS >> Database

Die Zombie-PerfMon-Zähler, die niemals sterben!

Eines der Dinge, die gleichzeitig großartig und schrecklich am Internet sind, ist, dass, sobald etwas im Äther gepostet wird, es im Grunde nie wieder verschwindet. (Eines Tages werden Politiker dies erkennen. Wir können ihre Konsistenz leicht überprüfen.) Aufgrund der Langlebigkeit von Inhalten, die im Internet veröffentlicht werden, werden viele Themen zur Leistungsoptimierung zu "Zombies". Wir schießen sie tot, aber sie kommen immer wieder!

Mit anderen Worten, diese alten Empfehlungen waren vor langer Zeit eine empfohlene bewährte Methode für eine bestimmte Version von SQL Server, sind aber jetzt für die neuere Version ungeeignet. Wenn ich auf einer Konferenz spreche, ist es nicht ungewöhnlich, dass ich auf jemanden treffe, der immer noch an Einstellungen und Techniken festhält, die seit den Tagen von SQL Server 2000 keine gute Praxis mehr waren. Das SQL Server 2000 Operations Guide on Capacity/Storage enthält viele Best-Practice"-Empfehlungen, die sehr versionsspezifisch waren und heute nicht mehr gelten.

Also hier ist ein Beispiel. Die % Disk Time und Disk Queue Length PerfMon-Zähler wurden dringend als wichtige Leistungsindikatoren für die E/A-Leistung empfohlen. SQL Server wirft mithilfe von Scatter/Gather viele E/A-Vorgänge auf die Datenträger, um die Auslastung des datenträgerbasierten E/A-Subsystems zu maximieren. Dieser Ansatz führt zu kurzen Bursts mit langen Warteschlangentiefen während Checkpoints und Vorauslesen für eine Instanz von SQL Server. Manchmal ist die Serverauslastung so groß, dass Ihre Festplatte nicht mit der E/A Schritt halten kann, und wenn das passiert, werden Sie auch lange Warteschlangen sehen. Das kurze Burst-Szenario ist kein Problem. Das Szenario der Verlängerung der Warteschlangenlänge ist normalerweise ein Problem. Ist das also eine gute Vorgehensweise?

Mit einem Wort, nicht so sehr.

Diese Zähler können auf einer Instanz von SQL Server, die nur eine Festplatte hat, immer noch von Nutzen sein (obwohl das extrem ist selten heutzutage). Warum?

Der PerfMon-Zähler % Disk Time ist aus mehreren Gründen eine falsche Leistungsmetrik. Asynchrone E/A-Anforderungen werden nicht berücksichtigt. Es kann nicht sagen, wie das tatsächliche Leistungsprofil für ein zugrunde liegendes RAID-Set aussehen könnte, da es mehrere Laufwerke enthält. Der PerfMon-Zähler Disk Queue Length ist auch meistens nutzlos, außer auf SQL Servern mit einer einzigen physischen Festplatte, da der Cache des Festplattencontrollers verschleiert, wie viele E / A-Operationen tatsächlich in der Warteschlange anstehen oder nicht. Tatsächlich haben einige Festplatten sogar winzige Schreib-Caches, was die Frage weiter trübt, ob die I/O wirklich in einer Warteschlange irgendwo zwischen dem Betriebssystem und der Festplatte in einer Warteschlange steht oder es endlich geschafft hat zum CMOS auf der Festplatte.

Bessere E/A-PerfMon-Zähler

Anstatt diese PerfMon-Leistungsindikatoren zu verwenden, verwenden Sie Avg Disk Reads/sec , Avg Disk Writes/sec und Avg Disk Transfers/sec um die Leistung von Plattensubsystemen zu verfolgen. Diese Zähler verfolgen die durchschnittliche Anzahl von Lese-I/Os, Schreib-I/Os und kombinierten Lese- und Schreib-I/Os, die in der letzten Sekunde aufgetreten sind. Gelegentlich verfolge ich dieselben Metriken lieber nach Datenvolumen als nach der Rate der E/A-Vorgänge. Um diese Daten zu erhalten, sollten Sie diese Volume-spezifischen PerfMon-Zähler ausprobieren: Avg Disk Transfer Bytes/sec , Avg Disk Read Bytes/sec und Avg Disk Write Bytes/sec .

Verwenden Sie für die E/A-Leistung von SQL Server Dynamic Management Views (DMV)

Und sofern Sie nicht in einer Höhle gelebt haben, sollten Sie sicherstellen, dass Sie die Dynamic Management Views (DMVs) von SQL Server verwenden, um die E/A-Leistung für neuere Versionen von SQL Server zu überprüfen. Einige meiner Lieblings-DMVs für I/O sind:

  • sys.dm_os_wait_stats
  • sys.dm_os_waiting_tasks
  • sys.dm_os_performance_counters
  • sys.dm_io_virtual_file_stats
  • sys.dm_io_pending_io_requests
  • sys.dm_db_index_operational_stats
  • sys.dm_db_index_usage_stats

Wie verfolgen Sie also I/O-Leistungsmetriken? Welche verwenden Sie?

Ich freue mich darauf, von Ihnen zu hören!

Viel Spaß,
-Kev
–Folge mir auf Twitter!