linux:benchmarks

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

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 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++).

Using Bonnie++ for filesystem performance benchmarking

  • 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.

  • nhfsstone

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
  • xengine
  • zum belasten der CPU (prüfen von Systemstabilität) eignet sich cpuburn ganz gut.
  • contest: Kernelkompilationstests, eine ziemliche reale Aufgabe