Einfache Festplatten-Benchmarks für Linux

Der folgende Beitrag wird sich mit einigen einfachen Mitteln befassen, wie man seine Festplattenleistung unter Linux bestimmen kann. In einem späteren Beitrag werde ich komplexere Benchmarkprogramme, wie fio oder iozone ausführlicher beleuchten. Die ersten drei Programme hdparm, dd und bonnie++ sind Benchmarks. Im Anschluss kommen noch die Diagnoseprogramme iostat und iotop. Da ich zur Zeit sehr viel mit dem Dateisystem ZFS arbeite, werde ich hier an einigen Stellen eine Anmerkung dazu schreiben, da es hier ein paar Besonderheiten zu beachten gibt.

hdparm

Mit hdparm kann man schnell und simpel die Lesegeschwindigkeit einer ganzen Festplatte messen. In der folgenden Version wird der Cache der Festplatte mit verwendet, entsprechend groß sind die Ergebnisse:

sudo hdparm -tT /dev/sda

Die beiden Parameter stehen für -t („Perform device read timings“) und -T („Perform cache read timings“). Wie man sieht wird der Test auf eine ganze Festplatte (sda) ausgeführt. Es ist auch möglich, ein RAID-device (md) mit diesem Befehl zu testen.

/dev/md0:
Timing cached reads: 5320 MB in 2.00 seconds = 2662.40 MB/sec
Timing buffered disk reads: 490 MB in 3.01 seconds = 162.93 MB/sec

Aus dem Cache der Festplatte kann mit einer Geschwindigkeit von 2662.40 MB/s gelesen werden. Die 162.93 MB/s entsprechen der Geschwindigkeit des Linux Buffer-Caches und sind ein Indikator für den Durchsatz des Prozessors, Cache und RAM während des Tests.

Wenn wir die Geschwindigkeit ohne Cache haben wollen, was bei größeren Datenmengen auch die interessantere Zahl ist, wird der Parameter –direct vorangestellt:

sudo hdparm --direct -tT /dev/sda

Das mögliche Ergebnis kann so aussehen:

/dev/md0:
Timing O_DIRECT cached reads: 470 MB in 2.00 seconds = 234.53 MB/sec
Timing O_DIRECT disk reads: 492 MB in 3.01 seconds = 163.50 MB/sec

Dieser Test greift, wie bereits erwähnt, auf das ganze Device zu. Ein Test von modernen Dateisystemen, wie ZFS ist somit nicht möglich.

dd

Wenn wir eine gemountete Festplatte testen wollen (oder ein Dateisystem, wie ZFS) bietet sich der Befehl dd an. Der folgende Befehl schreibt aus dem /dev/zero-Verzeichnis eine Datei auf das Laufwerk, welche aus Nullen besteht und 1 Gigabyte groß ist. Achtung: Bei ZFS können an dieser Stelle bereits extrem hohe Werte zu sehen sein, wenn die Kompression aktiviert ist.

dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc

Eine möglichere Ausgabe wäre wie folgt:

1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 9.9427 s, 108 MB/s

Da die geschriebene Datei jetzt auch in Linux-Cache liegt, wird dieser für den Lesetest als erstes geleert:

echo 3 | sudo tee /proc/sys/vm/drop_caches

Anschließend wird die Datei gelesen und in das /dev/null-Verzeichnis (quasi in das Nichts) geschrieben.

dd if=tempfile of=/dev/null bs=1M count=1024

Mit folgender Ausgabe:

1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 7.98849 s, 134 MB/s

Führt man den Befehl erneut aus, wird die Datei direkt aus dem Cache gelesen und die Ergebnisse sind entsprechend höher, da nicht auf die Festplatte zugegriffen werden muss:

1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.456526 s, 2.4 GB/s

Bei ZFS sind mit aktivierter Kompression die Datenraten trotz geleertem Cache enorm hoch. Daher bietet es sich zumindest für den Lesetest an, eine nicht komprimierte Datei (eine ISO-Datei oder Videodatei zum Beispiel) mit dd zu lesen. Dadurch erhält man die bestmögliche Performance des ZFS-Pools:

dd if=/home/user/mein-video.avi of=/dev/null bs=1M

8107+1 Datensätze ein
8107+1 Datensätze aus
8501178368 Bytes (8,5 GB) kopiert, 27,6758 s, 307 MB/s

bonnie++

Waren die beiden oben genannten Mittel lediglich improvisierte Benchmarks, haben wir mit bonnie++ jetzt das erste richtige Benchmarkprogramm. Die Installation erfolgt ebenfalls über die Paketquellen. Danach kann man das Programm unmittelbar starten. Zum testen einer Festplatte muss diese gemountet sein. Danach kann mit dem Parameter -d ein Ordner bestimmt werden:

bonnie++ -d /home/user/

Mit diesen Standardeinstellungen startet Bonnie++ nun automatisch. Dabei wird erst ein Schreibtest durchgeführt (write), anschließend die geschreibene Datei gelesen und gleichzeitig an anderer Stelle neu geschrieben (rewrite) und als drittes die Datei noch einmal gelesen (read). Die Größe der Testdatei ist, sofern man sie nicht manuell festlegt, immer doppelt so groß, wie der verfügbare RAM. Der folgende (mehr oder weniger gut lesbare) Wust ist die Ausgabe des Programms auf einer Test-VM mit 1 GB RAM.

Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
test-pc 2G 334 99 64151 12 61973 11 1191 99 78035 6 4214 50
Latency 25371us 447ms 129ms 14657us 16934us 7395us
Version 1.97 ------Sequential Create------ --------Random Create--------
test-pc -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency 1202us 338us 424us 143us 33us 190us

In der 4. Zeile, die mit „test-pc“ beginnt, stehen die spannenden Werte. Hier sieht man, dass mit einer 2 GB großen Testdatei gearbeitet wurde. Die drei dahinter folgenden, fetten Zahlen geben die Messwerte für write, rewrite und read in kb/s an. Hier haben wir also ca. 64 MB/s schreibend, 61,9 MB/s umsortieren und 78 MB/s lesend.

Wie auch bei dem vorherigen Benchmark mit dd lassen sich die Testdaten von bonnie++ sehr gut komprimieren, sodass die Werte an dieser Stelle wieder das physikalisch mögliche überschreiten, da die Kompression die verarbeitbaren Datenmengen deutlich schneller abarbeiten kann. Hier ist meist wieder der Prozessor der begrenzende Faktor und nicht die Festplatte selbst:

Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
paul 15640M 72 99 368767 91 188165 65 324 99 744083 72 705.7 19
Latency 127ms 23802us 267ms 60414us 96016us 188ms
Version 1.97 ------Sequential Create------ --------Random Create--------
paul -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 18375 96 +++++ +++ 18069 98 16538 97 +++++ +++ 17972 97

iostat

Wie bereits in der Einleitung erwähnt, ist iostat kein Benchmarkprogramm sondern ein Diagnose-tool. Mit ihm kann die Auslastung aller angeschlossenen Devices in Echtzeit angezeigt werden. Installiert wird es über die Paketsammlung sysstat:

sudo apt-get install sysstat

Führt man iostat direkt aus, bekommt man (in Kilobyte) die gelesenen und geschriebenen Daten seit dem Systemstart zurück. Für die bessere Lesbarkeit bietet es sich an, mit dem Parameter -m die Zahlen in Megabyte anzeigen zu lassen. Eine nachgestellte Zahl „n“ sagt iostat, dass es alle n Sekunden einen Mittelwert für diese Zeitspanne angeben soll. Gleichzeitig werden auch ein paar Daten über die CPU mit angegeben. Hier kann man z.B. an einem hohen %iowait-Wert sehen, dass die CPU auf die Festplatte warten muss und diese stark ausgelastet ist.

[email protected]:~$ iostat -m 2
Linux 3.13.11-ckt29 (ip-10-0-0-203) 12/04/2015 _x86_64_ (1 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.63 0.00 0.65 0.40 0.10 98.22

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
xvda 4.84 0.19 0.21 4394 4950

avg-cpu: %user %nice %system %iowait %steal %idle
0.00 0.00 4.12 94.71 1.18 0.00

Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
xvda 648.82 0.01 80.88 0 137

Seit dem Systemstart hat das oben angezeigte System bereits 4394 MB gelesen und 4950 MB geschrieben. Darunter sehen wir, dass in der 2-sekündigen Messzeit 137 MB geschrieben wurden, was einer Datenrate von 80.88 MB/s entspricht. Für den Anfang möchte ich auch bei diesem Programm nicht weiter ins Detail gehen und verweise auf die Man-Pages mit dem Befehl „man iostat“

iotop

Dieses Programm benötigt zwingend root-Rechte zur Ausführung und gibt die Gesamtauslastung des Systems an und schlüsselt (ähnlich wie der Befehl top für die CPU) die Top-Verursacher auf. Dabei wird zwischen den Werten actual und total für Schreib- und Lesevorgänge unterschieden. Unter total versteht man die Schnittstelle zwischen Programm und Kernel und actual zwischen Kernel und der Festplatte. Werden zum Beispiel nur sehr kleine Datenmengen geschrieben, cacht der Kernel diese zwischen und schreibt sie nach spätestens 5 Sekunden auf die Festplatte. Bei einer sehr hohen Belastung, wie einem Benchmark mit bonnie++, ähneln sich diese beiden Werte natürlich sehr. Der folgende Auszug zeigt eine solche Benchmark-Situation:

Total DISK READ : 120.94 K/s | Total DISK WRITE : 152.41 M/s
Actual DISK READ: 120.94 K/s | Actual DISK WRITE: 136.07 M/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
353 be/4 root 0.00 B/s 0.00 B/s 0.00 % 93.31 % [kworker/u16:1]
16296 be/4 stoerteb 0.00 B/s 152.40 M/s 0.00 % 48.79 % bonnie++
4059 be/4 minecraf 0.00 B/s 7.56 K/s 0.00 % 0.00 % java -ser~.jar nogui
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
5 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
7 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcu_sched]
8 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [rcuos/0]

Bonnie++ schreibt mit einer Datenrate von 152.40 MB/s auf die Festplatte. Die Spalte „IO“ gibt dabei an, wie hoch die Festplatte ausgelastet ist. In diesem Fall ist sie nahe der 100% und somit unter Volllast. Der kworker-Prozess ist ein Kernel-Prozess, welcher sich um die IOps kümmert, in diesem Fall die von bonnie++. Deshalb steht auch trotz einer Datenrate von 0 MB/s eine IO-Auslastung von 93 Prozent hinter diesem Prozess.

Das solls fürs erste gewesen sein. Wenn es fragen gibt, schreibt sie in die Kommentare, ich helfe gerne!

Stay tuned – Støertebeker

Veröffentlicht unter Allgemein, Linux, Tutorials

Schreibe einen Kommentar