Testen mittels DISKSPD

In diesem Artikel widmen wir uns dem Analysetool und Open-Source Software DISKSPD. Wofür dieses Tool gedacht ist und wie es in der Anwendung funktioniert, lesen Sie in den folgenden Abschnitten.

Was ist DISKSPD

DISKSPD ist ein Befehlszeilentool für Mikrobenchmarking. Es dient beispielsweise zum Vorab-Testen eines Clusters oder bei der Einrichtung eines physischen Servers. Es imitiert ein Szenario, welches einem echten synthetischen Workload nahe kommt.

Analyse von Festplatten

Mithilfe von diskspd können Sie analytische Daten zu Ihren “Festplatten” erhalten. Diese werden aus anpassbaren Benchmarks gemessen und können hinterher ausgegeben werden. Doch warum ist das wichtig für SQL Server?

Alle Daten, die sich in einer Datenbank befinden, werden auf Festplatten gespeichert. Über Queries können diese Daten verändert oder abgerufen werden. Dies sollte im besten Fall auch zügig funktionieren. Jedoch stellen Festplatten hierbei einen Flaschenhals dar. Wenn die Festplatten nur eine niedrige Lese- und Schreibgeschwindigkeit haben, können auch die am besten optimierten Queries nur sehr langsam ausgeführt werden. Um das zu verhindern, sollten Sie sich im vorhinein überlegen, welche Anforderungen ihr System benötigt. Hierbei kann diskspd helfen. Denn mit diesem Tool können tatsächliche Werte der Festplatte über personalisierte Testläufe gemessen werden. Somit kann man entscheiden, ob die Hardware für die Anforderungen ausreicht, oder ob mehr Leistung in Form von schnelleren Platten benötigt wird.

Hilfreiche Werte

Doch welche Werte gibt es und was sagen diese aus?

• IOPS: Oder auch Input/Output Operations per Second. Wie der Name schon sagt, gibt dieser Wert an, wie viele Lese- und Schreib-Operationen pro Sekunde vorgenommen werden können. Häufig wird die Unterscheidung zwischen Reads/s und Writes/s gemacht.
• Durchsatz (Throughput): Mit dem Durchsatz wird beschrieben, wie viele Bytes an Daten pro Sekunde übertragen werden können. Häufig wird dieser Wert in MB/s angegeben. Wenn man nur konstant kleine Mengen an Daten übertragen will, reicht ein kleinerer Throughput aus. Bei größeren Daten auf einmal, kann es dagegen zur Verlangsamung kommen.
• Latenz (Latency): Die Latenz gibt an, mit viel Verzögerung die Festplatte auf Anfragen des Systems reagiert. Dabei handelt es sich hier nur um Millisekunden. Wenn konstant viele Daten verändert werden, sollte die Festplatte eine niedrige Latenz haben.

Nutzen von diskspd

Die Software diskspd kann man im GitHub Repository von Microsoft herunterladen. Hier können Sie auf der rechten Seite den neuesten Release auswählen. Nach dem Download muss das Ganze entpackt werden. Da das Programm über die Kommandozeile ausgeführt wird, empfiehlt es sich, den Ordner an einen schnell erreichbaren Ort zu legen. Wichtig ist darauf zu achten, dass man in der Kommandozeile zur richtigen Version navigiert. Für ein 64-bit Betriebssystem wäre das der amd64 Ordner.

Es gibt verschiedene Parameter, die man dem Befehl übergeben kann. Das können neben der Dauer eines Testlaufs, der Anzahl von Threads und der Größe einer Testdatei auch noch weitere Einstellungen sein, wie z.B. die Verteilung von Read- und Write-Anfragen oder das Deaktivieren des Caching sein. Bevor wir jedoch auf jeden Parameter einzeln eingehen, wollen wir uns lieber an einem Beispiel anschauen, wie man das Ergebnis liest. Eine komplette Übersicht der Parameter erhalten Sie, wenn Sie einfach nur diskspd eingeben. Unter Umständen hilft es, wenn das Terminal als Administrator ausgeführt wird.

Lesen der Ergebnisse

Führt man einen Testlauf aus, kann das Ergebnis sehr erschlagend wirken. Denn es handelt sich hierbei um eine einfache Textdatei mit vielen Zahlen. Darum wollen wir nun von oben nach unten durchgehen, welche Werte man wo finden kann.

Zu Beginn der Datei steht der ausgeführte Befehl, der den Test gestartet hat. Darunter werden alle Parameter aufgelistet, die im Befehl angegeben wurden. Der Test hatte eine Laufzeit von 5min (300s), der Software- und Hardware-Cache war deaktiviert und wir hatten eine Read/Write Verteilung von 70/30. Das Ganze bei einer Blockgröße von 8KB und max. 32 ausstehenden I/O Operationen pro Thread.

Scrollt man weiter runter, stößt man auf die erste Tabelle. Kurz darüber steht, mit wie vielen Threads der Test gelaufen ist. In der Tabelle dazu kann man erkennen, welche Auswirkung dies auf die Auslastung der einzelnen CPU Kerne hatte. Wir hatten über den Parameter -t für jeden der vier Kerne einen separaten Thread eingestellt. Die Idle Zeit gibt an, wie viel Leerlauf der CPU Kern hatte. Daraus lässt sich ableiten, dass mehr Rechenkapazität vorhanden war, als letztendlich benötigt wurde.

Darunter lässt sich folgende Tabelle finden. Hier ist aufgeführt, wie viele Read- und Write-Operationen jeder Thread gemacht, wie viele Bytes damit verarbeitet wurden und mit welchem Throughput und mit welcher durchschnittlichen Latenz das Ganze passiert ist. All diese Daten werden in der letzten Zeile aufaddiert bzw. gemittelt, damit man eine Übersicht über alle Threads hinweg hat.

In den nächsten beiden Tabellen lassen sich die I/O Daten differenziert nur für Reads und Writes betrachten. Die Tabellen sind dabei genau so aufgebaut, wie die Total IO Tabelle. Verrechnet man die Werte für Read IO und Write IO, sollten dieselben Werte herauskommen, wie in der entsprechenden Tabelle zu den Total I/Os.

Gehen wir nun zum letzten Teil über, der vielleicht am schwersten zu verstehen ist. Jede Operation hat eine gewisse Wartezeit, bevor diese ausgeführt werden kann. Hält man diese Zeiten fest, kann man eine gewisse Verteilung der Werte feststellen. Manche Werte werden häufiger eintreten als andere. Man erhält somit eine Wahrscheinlichkeitsverteilung. Doch wie liest man diese Verteilung aus der Tabelle aus?

In der linken Spalte sind verschiedene Perzentile angegeben. Bei einer Wahrscheinlichkeitsverteilung werden alle Werte in 100 gleichgroße Teile unterteilt. Ein Perzentil ist somit ein Prozent aller Werte. Schaut man sich nun die Tabelle an, gibt es sowohl einen min-, als auch einen max-Wert. Nimmt man beide Werte als Intervallgrenzen, befinden sich alle gemessenen Wartezeiten innerhalb dieses Intervalls. Das Minimum stellt dabei die Wartezeit dar, die mindestens zu erwarten ist. Das bedeutet, es gab keine Operation die schneller ausgeführt werden konnte. Das Gegenteil zählt für das Maximum. Es gab keinen Wert, der langsamer war. In unserem Beispiel bedeutet das, dass wir Wartezeiten zwischen 0,061ms und 171,431ms hatten.

Das ist jedoch ein sehr großes Intervall und gerade die Randwerte sind immer unwahrscheinlicher, als die Werte in der Mitte des Intervalls. Darum ist der nächste Wert, den wir uns anschauen wollen, das 50. Perzentil, oder auch der Median. Dieser Wert ist das arithmetische Mittel. Das heißt, die Hälfte aller Werte sind kleiner und die andere Hälfte größer als der Median. In unserem Beispiel haben wir somit einen Mittelwert von 34,194ms. Dieser ist jedoch nicht mit dem Durchschnitt zu verwechseln. Diesen konnten wir in der Total IO Tabelle ablesen und weicht vom Median ab.

Die nächsten beiden wichtigen Werte sind das 25. und 75. Perzentil. Nimmt man diese als untere und obere Schranke, befinden sich in diesem Intervall die Hälfte aller Werte. Das heißt man kann davon ausgehen, dass jede zweite Operation eine Zeit in diesem Intervall hat. Von den übrigen 50% ist ein Viertel kleiner als die untere Schranke und ein Viertel größer als die obere Schranke.

Die letzten Werte zum erklären sind die Worst-Case Zeiten. Der Eintrag des 99. Perzentils bedeutet, dass 1% der Operationen eine längere Wartezeit hat. Die Einträge die darauf folgen, hängen eine weitere 9 hinter das Komma an (z.B. 3-nines → 99,9; 4-nines → 99,99; usw). Diese Zeiten werden somit immer unwahrscheinlicher. Anhand dieser Zeiten kann man sich überlegen, ob die Latenz akzeptabel ist, oder eine andere Festplatte benötigt wird.

Beispiele

Nachdem wir nun wissen, wie wir das Ergebnis eines Tests lesen können, wollen wir uns die verschiedenen Test Optionen anschauen. Das Beispiel, welches wir oben genutzt haben, ist ein Beispiel einer klassischen OLTP Belastung. Der Befehl dazu sieht wie folgt aus.

Gehen wir einmal schrittweise durch, welche Option was bewirkt.

Als erstes haben wir die Dauer des Tests festgelegt. Dies geht mit -d<Dauer> und der Dauer in Sekunden. In diesem Fall haben wir 5min gewählt (300s).

Mit -t<Anzahl> kann man festlegen, mit wie vielen Threads gearbeitet werden soll. Wir haben für jeden CPU Kern einen Thread genommen.

Dahinter haben wir festgelegt, wie viele ausstehende Anfragen pro Thread zugelassen werden. Das geht mit -o<Anzahl>.

Die Daten werden von SQL Server in Blöcken gespeichert. Diese haben standardmäßig eine Größe von 8KB. Das haben wir hier festgelegt mit -b8K.

Die Option -w<Wert> ermöglicht uns, zu bestimmen, wie viel Prozent des Workloads aus Write Operationen besteht. Der Rest fällt automatisch Read Operationen zu. Da wir ein OLTP Szenario nachbauen wollten, haben wir ein Verhältnis von 70/30 Reads/Writes gewählt.

Mit -r wird ein randomisierter I/O Zugriff festgelegt. Dies kann mit -s zu einem sequentiellen Zugreifen geändert und überschrieben werden.

Für unseren Fall haben wir zunächst sowohl Software, als auch Hardware Caching mit -Sh (S für Software, h für Hardware) deaktiviert. Will man Caching nutzen, lässt man diesen Parameter weg.

Da wir auch die Latenz messen wollen, aktivieren wir dies mit -L.

Als nächstes wollen wir noch festlegen, wie groß unsere Testdatei sein soll. Hier haben wir uns für 500GB entschieden. Mit -c<Wert>(M,K,G,..) kann aber jeder andere Wert auch in KB, MB, usw. gewählt werden.

Der Pfad zur Testdatei kann einfach so angegeben werden. Damit wir am Ende die Ergebnisse auch speichern können, geben wir eine Datei an, in die das Ganze übergeben werden soll (hier mit: > <Filename>.txt). Der diskspd Befehl stellt ziemlich gut die Last dar, die Datenfiles auf eine Festplatte haben. Besonders ist hierbei, dass mehr Leseoperationen anfallen.

Häufig werden Log Files auf eine andere Festplatte gespeichert. Dies liegt daran, dass sich hier die Anforderungen leicht ändern. Anstelle von vielen Reads, werden hier mehr Writes benötigt. Darum eignet sich hier folgendes Testbeispiel.

In diesem Fall haben wir einfach nur die Anteile an Write-Operationen erhöht und einen sequentiellen Zugriff angewandt.

Die Möglichkeiten, einen Test zu entwerfen, sind sehr groß. So kann man mit dem Weglassen der Option -Sh schauen, was die Festplatte mit Caching kann. Oder man ändert die Blockgröße zu 64KB Blöcken oder testet die reinen Write oder Read Fähigkeiten der Festplatte. All dies ist davon abhängig, welche Anforderungen gestellt werden und wie der Workload aussehen soll. Zur Hilfe können Sie sich weitere Testfälle im Wiki des Git Repository anschauen.

Fazit

Diskspd ist ein hilfreiches und kostenloses Tool, um die tatsächlichen Eigenschaften Ihrer Festplatte festzustellen. Wir hoffen, wir konnten Ihnen mit diesem Artikel zeigen, wie man Testfälle an die eigenen Anforderungen anpassen kann und wie die dabei resultierenden Ergebnisse gelesen werden. Sollten Sie darüber hinaus weitere Fragen haben, können Sie gerne über unser Kontaktformular einen unverbindlichen Termin mit unseren Expert:innen ausmachen.