Linux Benchmarks & Test tools
auch unter Linux gibt es natürlich eine gute Auswahl an Benchmarks, also Programme zum testen der Hardware auf „Flaschenhälse“.
Linux Test Tools - gute Übersicht nach Kategorien Linux Benchmark Suite Homepage Linux Benchmarking HOWTO
Test-suiten
I/O
- tiobench : für I/O- und Multitheading-Benchmarking
- sysbench (Realistische I/O-Load-Messung mit Unterstützung der MySQL-Datenbank) siehe auch: Compiling sysbench 0.4.12 for Debian und Evaluating IO subsystem performance for MySQL Needs
other:
- dbench (synthetisch)
- postmark (gibts auch für NT): geeignet für kleine Dateien (mail und news-Server)
Je nach Benchmark ist ggf. das Löschen der Caches sinnvoll:
drop_caches Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free. To free pagecache: echo 1 > /proc/sys/vm/drop_caches To free dentries and inodes: echo 2 > /proc/sys/vm/drop_caches To free pagecache, dentries and inodes: echo 3 > /proc/sys/vm/drop_caches As this is a non-destructive operation and dirty objects are not freeable, the user should run `sync' first.
dbench
dbench 10 -t 60 -c results.txt
dd
funktioniert immer, für sequentielle Schreib/Lesetests ok.
dd if=/dev/zero of=/ziel/testfile.dd bs=1000M count=1 oflag=direct
Mit Zufallsdaten um Kompressions-/dedup-Effekte auszuschließen (z.B. bei SSDs):
sudo dd if=/dev/urandom of=randfile bs=1M count=1024 && sync sudo dd if=randfile of=/dev/ZIEL bs=4k count=100000 oflag=direct,dsync
fio
sudo fio --filename=/dev/ZIEL --size=20G --direct=1 --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=Schreibtest
siehe „man fio“, wichtig sind z.B. –direct für O_DIRECT-Zugriff (ohne Kernel page cache) und –sync für syncrone (O_DSYNC)-Zugriff um Schreibcaches abzuschalten.
IOMeter
IOMeter ist ein Festplattenbenchmark, der neue Entwicklungen (z.B. Dualcore und NCQ von Sata) besser berücksichtigt. IOMeter Download
hdparm-test
mit dem Standard-tool hdparm kann man die Interfacegeschwindigkeit und eine groben Geschwindigkeitstest machen. Dabei werden aber nicht unterschiedliche Zonen bewertet.
sudo hdparm -T /dev/hda
bzw.
sudo hdparm -t /dev/hda
(hda ändern auf anderen Wert wenn nötig) siehe hdparm Handbuch
bonnie++
bonnie++ start beim Aufruf einen Festplattentest im aktuellen Verzeichnis und gibt dann auf der Standardausgabe einen Report aus, den man mit bon_csv2html zu einer html-Datei verarbeiten kann. Dazu wird/werden die letzten Zeile(n) ausgewertet.
Bei einem Server mit 32GB RAM und Benutzer „benchuser“ :
bonnie++ -r 32768 -u benchuser > output.txt
Mehrere Pluszeichen weisen darauf hin das der Testlauf zu schnell fertig war um präzise Messergebnise zu erhalten. Es muss mit -n
die Anzahl der Dateien hochgesetzt werden.
bonnie++ -r 32768 -n 4 -u benchuser > output.txt
Einen einzelnen Testlauf kann man durch Pipes direkt als html-Datei ausgeben lassen:
bonnie++ | tail -n 1 | bon_csv2html > report.html
bei umfangreichen Testläufen sollte man sich die Ergebnisse abspeichern und kann sie dann später verarbeiten (etwa so: bonnie++ > bonnie-report.txt
). Man kann sich die Ergebnisse auch als Textdatei aufbereiten lassen (mit csv2txt).
Wichtig sind bei den Ausgaben von bonnie++ dabei immer die Zeilen am Ende (im CSV-Format) die in etwa so aussehen:
Rechnername,3G,16310,45,26006,15,15854,5,19301,50,32735,6,131.5,0,16,+++++,+++,+++++,+++,30870,82,29483,82,+++++,+++,23010,61
wobei die Tests (bzw. die Daten) mit „+++“ nicht aussagekräftig genug waren.
Die Optionen (Anzahl der Testläufe etc.) findet man im Handbuch (man bonnie++
).
iozone3
CPU
Mailserver
Netzwerk
- netperf
- tbench (im dbench-Paket)
- netio (Protokolle: TCP/UDP/NetBIOS)
-
- Aufruf Server:
iperf -s
(wartet per default auf Port 5001 auf Verbindungen
- Aufruf Client: z.B.
iperf -P 1 -i 1 -p 5001 -w 56K -f k -t 10 -c SERVER-IP
Zwei Netzwerkkarten im gleichen Server zu testen ist (ohne weitere Verrenkungen) nicht möglich, der Kernel erkennt das dies ineffizient ist. Dennoch gibt es Lösungen zu diesem "Problem", getestet habe ich diese Lösung.
DNS
NFS
- nhfsstone
SMTP
- smtp-source (ein SMTP/LMTP Nachrichtengenerator) und smtp-sink (nimmt Nachrichten an und verwirft diese) von Wietse Venema (siehe http://www.postfix.org/TUNING_README.html)
smtp-sink Beispiel: Der Rechner „blackhole.domain.tld“ soll auf Port 25 (SMTP) 80000 mails entgegennehmen (und verwerfen). smtp-sink läuft als Benutzer „maildrop“, da root nicht erlaubt ist.
smtp-sink -u maildrop -c blackhole.domain.tld:25 80000
HTTP
z. B. mit 10 konkurrierenden Verbindungen und 50 Anfragen:
ab -n 50 -c 10 $URL
- siege
- httperf (bisher nicht in Debian stable sondern nur in testing + bei Ubuntu enthalten)
X-Server
- xengine
Stresstests
- zum belasten der CPU (prüfen von Systemstabilität) eignet sich cpuburn ganz gut.
- contest: Kernelkompilationstests, eine ziemliche reale Aufgabe