Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
linux:benchmarks [2014/09/27 20:29] – [Netzwerk] st | linux:benchmarks [2020/05/04 19:09] (aktuell) – [fio] st | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ====== Linux Benchmarks & Test tools ====== | ||
+ | auch unter Linux gibt es natürlich eine gute Auswahl an Benchmarks, also Programme zum testen der Hardware auf " | ||
+ | |||
+ | [[http:// | ||
+ | [[http:// | ||
+ | [[http:// | ||
+ | |||
+ | |||
+ | ===== Test-suiten ===== | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | |||
+ | ===== I/O ===== | ||
+ | |||
+ | * [[http:// | ||
+ | * **tiobench** : für I/O- und Multitheading-Benchmarking | ||
+ | * [[http:// | ||
+ | |||
+ | other: | ||
+ | * dbench (synthetisch) | ||
+ | * [[http:// | ||
+ | |||
+ | 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 > / | ||
+ | To free dentries and inodes: | ||
+ | echo 2 > / | ||
+ | To free pagecache, dentries and inodes: | ||
+ | echo 3 > / | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | <code bash>dd if=/ | ||
+ | |||
+ | Mit Zufallsdaten um Kompressions-/ | ||
+ | <code bash> | ||
+ | sudo dd if=randfile of=/ | ||
+ | | ||
+ | ==== fio ==== | ||
+ | |||
+ | <code bash> | ||
+ | |||
+ | 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, | ||
+ | [[http:// | ||
+ | |||
+ | ==== 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 [[http:// | ||
+ | |||
+ | ==== 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 " | ||
+ | |||
+ | 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 '' | ||
+ | |||
+ | 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: '' | ||
+ | |||
+ | Wichtig sind bei den Ausgaben von bonnie++ dabei immer die Zeilen am Ende (im CSV-Format) die in etwa so aussehen: | ||
+ | < | ||
+ | Rechnername, | ||
+ | </ | ||
+ | wobei die Tests (bzw. die Daten) mit " | ||
+ | |||
+ | Die Optionen (Anzahl der Testläufe | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | ==== iozone3 ==== | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===== CPU ===== | ||
+ | |||
+ | ===== Mailserver ===== | ||
+ | [[http:// | ||
+ | |||
+ | |||
+ | ===== Netzwerk ===== | ||
+ | |||
+ | * netperf | ||
+ | * tbench (im dbench-Paket) | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * Aufruf **Server**: < | ||
+ | * Aufruf **Client**: z.B.< | ||
+ | |||
+ | :!: Zwei Netzwerkkarten im gleichen Server zu testen ist (ohne weitere Verrenkungen) nicht möglich, der Kernel erkennt das dies ineffizient ist. Dennoch gibt es [[http:// | ||
+ | ==== DNS ==== | ||
+ | |||
+ | [[ftp:// | ||
+ | |||
+ | ==== NFS ==== | ||
+ | * nhfsstone | ||
+ | |||
+ | ==== SMTP ==== | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | |||
+ | **smtp-sink Beispiel**: Der Rechner " | ||
+ | |||
+ | <code bash> | ||
+ | ==== HTTP ==== | ||
+ | * [[http:// | ||
+ | z. B. mit 10 konkurrierenden Verbindungen und 50 Anfragen: | ||
+ | < | ||
+ | * siege | ||
+ | * httperf (bisher nicht in [[debian: | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | |||
+ | ===== X-Server ===== | ||
+ | * xengine | ||
+ | |||
+ | |||
+ | |||
+ | ===== Stresstests ===== | ||
+ | * zum belasten der CPU (prüfen von Systemstabilität) eignet sich cpuburn ganz gut. | ||
+ | * contest: Kernelkompilationstests, |