Die Leistungsfähigkeit eines Servers besteht neben der CPU-Leistung oder auch RAM-Ausstattung aus der Leistungsfähigkeit der Speichermedien. Diese setzt sich zusammen aus Lese- und Schreibperformance. Diese ist nochmals unterteilt in unterschiedliche Datengrößen und unterschiedliche Reihenfolgen (Sequenziell oder auch nicht).
Ein Schönes Tool, um einen Festplatten-Benchmark durchzuführen ist Bonnie++. Es zeigt nämlich mehr Informationen, als nur sequentielles lesen/schreiben, da das einen in der Realität eher untergeordneten Anwendungsfall beschreibt.
Als Testwerkzeug kommt mein aktuellen Spielzeug, ein RaspberryPi (Model B mit 512 MB SDRAM) zum Einsatz. Hier ist eine SanDisk Extreme Class 10 SD-Karte eingesetzt. Mit dieser Karte sind nach Angaben des RPi Wikis etwa 20MB sowohl lesend als auch schreibend möglich ( http://www.elinux.org/RPi_SD_cards ). Diese Werte zeigen die sequentielle Geschwindigkeit, anwendbar für große Dateien, die an einem Stück auf die Karte/Festplatte geschrieben wurden.
Als Betriebssystem kommt Raspbian ( http://www.raspbian.org/ ) zum Einsatz, welches speziell für die ARM Architektur des Raspberry kompiliert wurde und auf Debian aufsetzt:
cat /etc/issue Raspbian GNU/Linux 7 \n \l
Als erstes wird bonnie++ installiert. Wie unter Debian gewohnt funktioniert das mit apt-get ganz einfach:
sudo apt-get update sudo apt-get install bonnie++
Bei der Ausführung von bonnie++ ist zu beachten, dass es als Standard Dateien in Doppelter RAM-Größe auf die Platte schreibt. Bei einem System mit 512MB RAM also eine 1GB-große Datei.
Die Ausführung von Bonnie gestaltet sich sehr einfach im Home-Verzeichnis des aktuellen Users (für die Lese/Schreibrechte). Hierbei wird immer das Verzeichnis als Grundlage für die Tests verwendet, in dem man aktuell ist:
cd ~ bonnie++
Die Ausgabe sieht folgendermaßen aus:
Okay, diese Ausgabe ist wohl ein wenig kryptisch und sehr kompakt 😉 Um die Ergebnisse etwas schöner dargestellt zu bekommen, nutzen wir ein kleines Helferlein:
bonnie++ | tail -n 1 | bon_csv2html > $(date +"%Y.%m.%d.%S.%N")_bonnie.html
Das generiert eine kleine HTML-File, welche im Browser betrachtet werden kann und in meinem Beispiel so aussieht:
Jetzt können die Werte eindeutig den entsprechenden Überschriften zugeordnet werden. Links unter Size sieht man nun die Größe der sequentiellen Datei, die verwendet wurde. Wie erwartet steht hier 1GB, das entspricht der doppelten Größe des RAM.
Was unter den einzelnen Werten zu verstehen ist, kann auf dem oracle Blog nachgelesen werden: https://blogs.oracle.com/roch/entry/decoding_bonnie . Der Author hat bonnie++ im Detail analysiert und zeigt die Operationen, welche mit bonnie durchgeführt werden.
Nehmen wir nun als weiteres Beispiel den HP Microserver N54L mit Openmediavault her und führen auf dem Raid-System den Befehl (unter einem nicht-root-User mit entsprechenden Schreibrechten im Verzeichnis) aus:
bonnie++ -n 512 -r 4096 -u admin | tail -n 1 | bon_csv2html > $(date +"%Y.%m.%d.%S.%N")_bonnie.html
Dabei steht -n 512 für die Anzahl der Dateien, die für eine korrekte Ermittlung der rechten Ergebnisse (wo statt einer Zahl mehrere „+“ stehen) verwendet werden soll. Das -r 4096 beeinflusst die Größe der Datei, es repräsentiert den angenommenen RAM-Wert. Durch -u wird der Benutzer gewählt, der nicht root ist (hier: admin, als root verweigert bonnie++ den Dienst). Das Ergebnis zeigt ein RAID 5 mit 4 Seagate-Platten a 3 TB:
Diese Daten zeigen sehr schön, dass ich eine neue CPU benötige 😉 Spaß beiseite, die Performance ist recht ordentlich und geeignet, um eine GBit-Leitung beim schreiben von großen Dateien nahezu auszulasten.
Hier auf dem selben NAS auf einer günstigen SSD-Platte:
Und hier noch eines vom beschäftigten ESXi mit Hardware-RAID 5 (3 x 1,5TB), jedoch in der hässlichen Variante 😉 :
Zum Abschluss noch ein Synology NAS ds411 mit vier 2 TB Platten im RAID 5 Verbund:
bonnie++ -u root Using uid:0, gid:0. Writing a byte at a time...done Writing intelligently...done Rewriting...done Reading a byte at a time...done Reading intelligently...done start 'em...done...done...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.96 ------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 NAS 4G 375 97 46753 10 33824 8 2278 97 168125 18 1886 72 Latency 40693us 789ms 2454ms 15377us 88352us 367ms Version 1.96 ------Sequential Create------ --------Random Create-------- NAS -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 4666 13 +++++ +++ 5544 14 7576 27 +++++ +++ 11276 24 Latency 903us 1502us 2195us 530us 71us 3314us 1.96,1.96,NAS,1,1372701005,4G,,375,97,46753,10,33824,8,2278,97,168125,18,1886,72,16,,,,,4666,13,+++++,+++,5544,14,7576,27,+++++,+++,11276,24,40693us,789ms,2454ms,15377us,88352us,367ms,903us,1502us,2195us,530us,71us,3314us
Möchte man einen sehr einfachen Benchmark machen, könnte man sequentielles Lesen/Schreiben mit folgenden Befehlen testen:
cd <zu testendes verzeichnis> dd if=/dev/zero of=tempfile bs=1MB count=10240 dd if=tempfile of=/dev/zero bs=1MB count=10240
Dabei ist bs die Blocksize und count die Anzahl der Blöcke, die geschrieben, bzw. gelesen werden.
Die Ergebnisse könnten dabei beispielsweise so aussehen:
dd if=/dev/zero of=tempfile bs=1MB count=10240 10240+0 Datensätze ein 10240+0 Datensätze aus 10240000000 Bytes (10 GB) kopiert, 54,3475 s, 188 MB/s root@NAS:/media/efffb6d7-fed3-4bc0-b2d8-93ae8f533bc2# dd if=tempfile of=/dev/zero bs=1MB count=10240 10240+0 Datensätze ein 10240+0 Datensätze aus 10240000000 Bytes (10 GB) kopiert, 29,0899 s, 352 MB/s
Das Ergebnis ist nun deutlich leichter zu lesen und gibt auch wieder einen Anhaltspunkt für die Performance des Dateisystems.
Am Schluss möchte ich noch erwähnen, dass die Tatsächliche Leistung des Systems stark auf den Anwendungsfall ankommt. Die Testfälle geben nur eine grobe Richtung vor. Es kann durchaus sein, dass während des Betriebs die Werte deutlich von den Benchmarks abweichen. Beispielsweise wenn mehrere Benutzer gleichzeitig auf das System zugreifen.