Testen der SQL Server Speichersubsysteme mittels DISKSPD

Das Speichersubsystem ist einer der wichtigsten Faktoren in Sachen “SQL Server Performance”. Denn die SQL Server Speicher Engine sichert alle Datenbankobjekte, Tabellen und Indizes in physischen Dateien. Treten hier Speicherengpässe auf, wirkt sich das negativ auf die Leistung Ihres SQL Servers aus. Ein erster Ansatz wäre es, entsprechende Speichersubsysteme auf dessen Leistung und Speicherkapazitäten hin zu testen. Wir verwenden dafür DISKSPD und erklären in den folgenden Absätzen, wie wir vorgehen.

Bevor wir mit Diskspd starten, führen wir eine Festplattenmessung durch und gehen auf grundlegende Fachbegriffe ein:

→ IOPS sind Eingabe- bzw. Ausgabeoperationen pro Sekunde. Sie geben an, wie viele Operationen von der Festplatte pro Sekunde ausgeführt werden. Dies ist ein Indikator zur Bewertung der Speicherleistung. Es werden in diesem Vorgang jedoch nur die durchgeführten Transaktionen numerisch gezählt. Die Datenmenge wird dabei nicht berücksichtigt, sodass diese Metrik nicht als alleinige Entscheidungsgrundlage fungieren sollte.

→ Der Durchsatz (engl. Troughput) gibt im Gegensatz zu den IOPS die Datenmenge an, die die Speichereinheit pro Sekunde übertragen kann. Sie wird in MB/Sek. gemessen.

→ Letztlich ist noch die Latenz zu erwähnen. Diese gibt das Maß der Antwortzeit eines Speichermediums auf die empfangene Operation an. Gemessen wird hier in Einheit pro Millisekunde. Eine hohe Latenz wirkt sich daher bei Datenbanken negativ auf dessen Leistung aus. Wichtige Protokolldateien mit hohen Änderungsanforderungen sollten daher auf Speichermedien mit geringer Latenz gesichert werden.

Was ist DISKSPD?

Um das SQL Server Speichersubsystem hinsichtlich seiner Leistung zu untersuchen, verwenden wir DISKSPD. DISKSPD ist ein Testtool, welches die Fähigkeit auf Melden von Falsch-Auslastungen des Speichermediums überprüft. Sie können Ihre eigenen synthetischen Workloads erstellen um Anwendungen vor der Bereitstellung zu testen. Das tolle an dem Tool ist, dass es Ihnen die Möglichkeit bietet, die Parameter zu konfigurieren und zu optimieren, um ein bestimmtes Szenario zu erstellen, das Ihrem echten Workload sehr nahe kommt. Da diese Variante des Tests realistische und zuverlässige Ergebnisse liefert, bevorzugen Experten dieses Open-Source Tool. In Text- oder XML-Ausgabe werden Sie mittels Parametern über die Grenzen der Leistungsfähigkeit Ihrer Speichersubsysteme unterrichtet.

Um DISKSPD zu verwenden, müssen Sie das Tool zunächst installieren. Wir stellen über PowerShell eine Verbindung zum Zielserver her und geben folgenden Befehl ein:

Enter-PSSession -ComputerName <TARGET_COMPUTER_NAME>

Um DISKSPD herunterzuladen führen wir nun folgenden Befehl in PowerShell aus:

$client = new-object System.Net.WebClient
$client.DownloadFile("https://github.com/microsoft/diskspd/releases/download/v2.0.21a/DiskSpd.zip","<ENTER_PATH>\DiskSpd-2.0.21a.zip")

Anschließend entpacken Sie die Download Datei mit nachfolgendem Befehl:

Expand-Archive -LiteralPath <ENTERPATH>\DiskSpd-2.0.21a.zip -DestinationPath C:\DISKSPD

Sie erhalten nun einen Ordner mit Zip Dateien mit 3 Releases des Tools und wählen die für Ihr Betriebssystem zugehörige Datei aus.

  • amd64 : Für 64-Bit-Betriebssysteme
  • x86 : Für 32-Bit-Betriebssysteme
  • ARM64: Für 32-Bit-Betriebssysteme

Um Diskspd auszuführen, führen Sie folgenden PowerShell-Befehl aus. Ersetzen Sie alles innerhalb der eckigen Klammern, auch die Klammern selbst, durch Ihre entsprechenden Einstellungen.

.\[INSERT_DISKSPD_PATH] [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]

Diskspd ist ein Befehlszeilentool. Aus diesem Grund müssen Sie die Eingabeaufforderung mit Administratorrechten öffnen und dann in das Verzeichnis navigieren, in das Sie die diskspd.exe kopiert haben. Wenn Sie diskspd.exe ohne Parameter an der Eingabeaufforderung ausführen, werden Versionsdetails und alle Parameterbeschreibungen zurückgegeben.

Mit Diskspd können diverse Parameter ausgelesen werden. Davon gibt es eine Vielzahl, sodass wir Ihnen nachfolgend die Wichtigsten vorstellen:

ParameterBeschreibung
-BBlockgröße in Bytes und der Standardwert ist 64 KB
-DDie Dauer des Tests und der Standardwert beträgt 10 Sekunden
Die Anzahl der ausstehenden I/O-Anforderungen pro Ziel pro Thread und der Standardwert ist 2
-TAnzahl der Worker-Threads pro Datei
-hDeaktivieren von Hardware-Schreibcaching und Software-Caching
-RZufälliger E/A-Zugriff und kann mit dem Parameter –s überschrieben werden
-wProzentsatz der Schreibanfragen im Test
-CGibt die Größe der Datei an, die im Test verwendet wird
-LMessen Sie die Latenzinformationen

Mit dem vorhandenen Wissen und dem entsprechenden Testtool DISKSPD möchten wir nun ein OLTP Workload Szenario erstellen. Dieses Szenario basiert auf einem OLTP Workload mit hohen Schreibaktivitäten.

diskspd -b8K –d180 -h -L –o32 –t3 -r –w75 -c5G C:\Testdata\IO.dat > resultfile.txt
-b8K SQL Server speichert Daten auf den Seiten und diese Seitengröße beträgt 8 KB, daher werden wir den Blockgrößenparameter auf 8 KB setzen.
–d180die Dauer des Tests beträgt 180 Sekunden
-hDieser Parameter deaktiviert die Caching-Mechanismen, da SQL Server auf diese Weise funktioniert.
-LMit Hilfe dieses Parameters wird die Latenzstatistik in den Bericht aufgenommen.
-o32Die Warteschlangentiefe wird über diesen Parameter auf 32 eingestellt
-t3Dieser Parameter bestimmt die Anzahl der Threads.
-rSQL Server greift zufällig auf Datendateien zu. Aus diesem Grund setzen wir diesen Parameter auf zufällig.
-c50GDieser Parameter legt die Größe der Beispieldatei fest, die im Test verwendet wird.
-w75Die Arbeitslast des Tests beträgt 75 Prozent Schreiben und der Rest wird als Lesen ausgeführt, da die OLTP-Arbeitslast mehr Schreibaktivitäten als Lesen umfasst.
C:\Testdata\io.dat Der Name der Beispieldatei, die im Test verwendet wird.
resultfile.txt Die Ausgabedatei der Testergebnisse.

Nach der Ausführung des Tests werden die Ergebnisse in die Datei resultfile.txt geschrieben. Die Ergebnisse können wir in 4 Abschnitte unterteilen. Dies erleichtert uns die Interpretation der Testergebnisse. Der erste Abschnitt des Testergebnisses zeigt uns die Eingabeparameter und alle anderen Einstellungen.

Im zweiten Abschnitt finden wir die Details zur durchschnittlichen CPU-Auslastung.

Der Abschnitt Total IO enthält die Leistungsdetails der Speicherleistung. 54562 sind die für diesen Test insgesamt generierten IOPS und die Testdauer beträgt rund 180 Sekunden, sodass die IOPS pro Sekunde 54562/180 = 303,09 betragen . Die Spalte AvgLat gibt die durchschnittliche Latenz an und das Ergebnis ist 316,204 . Der Durchsatz pro Sekunde beträgt 2,37 MB/s .

Wenn wir die Ergebnisse interpretieren, sehen wir, dass die Speicherleistung und Latenzwerte nicht akzeptabel sind. Somit ist es für unseren Workload nicht sinnvoll, eine Datenbankinstallation auf diesem Speichermedium vorzunehmen. Der Abschnitt Read IO enthält Details zu den Leseoperationen und der Abschnitt Write IO enthält Details zu den Schreiboperationen.

Der letzte Abschnitt der Testergebnisse zeigt uns die Latenz-Perzentil-Analyse der Speicherleistung inklusive Minimalwert und Maximalwert. Dieses Ergebnis hilft herauszufinden, wie sich die Speichermedien unter Last verhalten.

LDF Workload-Szenario mit Protokolldatei: Der SQL Server-Protokollmechanismus verwendet ein Speichermedium, in den die Transaktionen geschrieben werden, bevor sie in die Protokolldatei geschrieben werden. Die Kapazität dieses Bereichs beträgt 60 KB und diese Protokolldaten werden in Blöcken von 60 KB auf die Festplatte geschrieben. Alternativ könnten SQL Protokolldateien auch sequentiell beschrieben werden. Angesichts dieser Informationen sieht der Leistungstestparameter wie folgt aus:

diskspd –b60K –d60 -h -L –o32 –t1 -s –w100 –c1G C:\Testdata\LogIO.dat > resultLogFile.txt

Read-Ahead-Szenario: Read-Ahead-Mechanismus wird von der SQL Storage Engine verwendet, um fortlaufende Datenseiten in das Speichersubsystem zu bringen, bevor die Daten überhaupt angefordert werden. Bei diesem Mechanismus kann die Speichermaschine 64 fortlaufende Datenseiten in das Subsystem übertragen. So können wir die Blockgröße des Leistungstests auf 512 KB einstellen.

diskspd –b512K –d120 -h -L –o32 –t3 -si –w100 –c1G -s C:\Testdata\AheadIO.dat > resultRdAhead.txt

Fazit

Mit dem Testtool Diskspd haben wir nun einige Szenarien aufgedeckt und erklärt, wie Sie mithilfe dessen die Leistung Ihrer SQL Speichersubsysteme testen können. Sie liefern wichtige Ergebnisse hinsichtlich der Speicherkapazitäten und ob es sich grundsätzlich lohnt, Datenbanktabellen auf das besagte Medium zu speichern. Auch decken sie Erkenntnisse auf, ob Ihr SQL Server Speichersubsystem zu gravierenden Leistungseinbrüchen aufgrund Fehlbelastung führen kann.