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
other:
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 10 -t 60 -c results.txt
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
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 ist ein Festplattenbenchmark, der neue Entwicklungen (z.B. Dualcore und NCQ von Sata) besser berücksichtigt. IOMeter Download
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++ 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++
).
iperf -s
(wartet per default auf Port 5001 auf Verbindungen
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.
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
z. B. mit 10 konkurrierenden Verbindungen und 50 Anfragen:
ab -n 50 -c 10 $URL