linux:benchmarks

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
linux:benchmarks [2008/12/13 16:21] – stlinux: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 "Flaschenhälse".
  
 +
 +[[http://ltp.sourceforge.net/tooltable.php|Linux Test Tools]] - gute Übersicht nach Kategorien
 +[[http://lbs.sourceforge.net/|Linux Benchmark Suite Homepage]]
 +[[http://tldp.org/HOWTO/Benchmarking-HOWTO.html|Linux Benchmarking HOWTO]]
 +
 +
 +===== Test-suiten =====
 +  * [[http://www.phoronix-test-suite.com/|Phoronix Test Suite]], [[http://www.phoronix.com/scan.php?page=article&item=phoronix_pts&num=1|Phoronix Test Suite Released]]
 +  * [[http://www.netlib.org/benchmark/hpl/|Linpack]]
 +
 +===== I/O =====
 +
 +  * [[http://linux.inet.hr/how_fast_is_your_disk.html|How fast is your disk?]]
 +  * **tiobench** : für I/O- und Multitheading-Benchmarking
 +  * [[http://sourceforge.net/projects/sysbench/|sysbench]] (Realistische I/O-Load-Messung mit Unterstützung der [[datenbanken:mysql|MySQL-Datenbank]]) siehe auch:  [[http://www.randombugs.com/linux/compiling-sysbench-0412-debian.html|Compiling sysbench 0.4.12 for Debian]] und [[http://www.mysqlperformanceblog.com/2008/03/05/evaluating-io-subsystem-performance-for-mysql-needs/|Evaluating IO subsystem performance for MySQL Needs]]
 +
 +other:
 +  * dbench (synthetisch)
 +  * [[http://www.netapp.com/tech_library/postmark.html|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:
 +<file>
 +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.
 +</file>
 +
 +==== dbench ====
 +
 +  dbench 10 -t 60 -c results.txt
 +  
 +==== dd ====
 +funktioniert immer, für sequentielle Schreib/Lesetests ok.
 +
 +<code bash>dd if=/dev/zero of=/ziel/testfile.dd bs=1000M count=1 oflag=direct</code>
 +
 +Mit Zufallsdaten um Kompressions-/dedup-Effekte auszuschließen (z.B. bei SSDs):
 +<code bash>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</code>
 +  
 +==== fio ====
 +
 +<code bash>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</code>
 +
 +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.
 +[[http://www.iometer.org/doc/downloads.html|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 [[http://www.die.net/doc/linux/man/man8/hdparm.8.html|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:
 +<file>
 +Rechnername,3G,16310,45,26006,15,15854,5,19301,50,32735,6,131.5,0,16,+++++,+++,+++++,+++,30870,82,29483,82,+++++,+++,23010,61
 +</file>
 +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++'').
 +
 +[[http://www.linux.com/feature/139742|Using Bonnie++ for filesystem performance benchmarking]]
 +
 +==== iozone3 ====
 +
 +[[http://www.linux.com/feature/139744|IOzone for filesystem performance benchmarking]]
 +
 +
 +
 +
 +===== CPU =====
 +
 +===== Mailserver =====
 +[[http://www.linux-magazin.de/heft_abo/ausgaben/2006/12/post_belastungsprobe?special=Groupware&category=16633|Mit dem Mailserver-Benchmark Postal Engpässen auf der Spur - Post-Belastungsprobe]] 
 +
 +
 +===== Netzwerk =====
 +
 +  * netperf
 +  * tbench (im dbench-Paket)
 +  * [[http://www.heise.de/software/download/netio/2155|netio]] (Protokolle: TCP/UDP/NetBIOS)
 +  * [[http://sourceforge.net/projects/iperf/|iperf]] / [[http://sourceforge.net/project/showfiles.php?group_id=128336&package_id=268197|jperf (plattformunabhängige Java-Variante)]]
 +    * Aufruf **Server**: <code>iperf -s</code> (wartet per default auf Port 5001 auf Verbindungen
 +    * Aufruf **Client**: z.B.<code>iperf -P 1 -i 1 -p 5001 -w 56K -f k -t 10 -c SERVER-IP</code>
 +
 +:!: 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://serverfault.com/questions/127636/force-local-ip-traffic-to-an-external-interface|Lösungen zu diesem "Problem"]], getestet habe ich [[http://serverfault.com/a/309442|diese Lösung]].
 +==== DNS ====
 +
 +[[ftp://ftp.nominum.com/pub/nominum/dnsperf/|dnsperf]] ([[http://snobbycloud.blogspot.de/2012/07/installing-dnsperf-to-ubuntu-1204.html|muss kompiliert werden]])
 +
 +==== NFS ====
 +  * nhfsstone
 +
 +==== SMTP ====
 +  * [[http://www.coker.com.au/postal/|postal]]
 +  * [[http://www.slamd.com/|SLAMD Distributed Load Generation Engine]]
 +  * [[http://www.postfix.org/smtp-source.1.html|smtp-source]] (ein SMTP/LMTP Nachrichtengenerator) und [[http://www.postfix.org/smtp-sink.1.html|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.
 +
 +<code bash>smtp-sink -u maildrop -c blackhole.domain.tld:25 80000</code>
 +==== HTTP ====
 +  * [[http://httpd.apache.org/docs/1.3/programs/ab.html|Apache Bench (ab): Apache Bestandteil]]
 +z. B. mit 10 konkurrierenden Verbindungen und 50 Anfragen:
 +<code>ab -n 50 -c 10 $URL</code>
 +  * siege 
 +  * httperf (bisher nicht in [[debian:Debian]] stable sondern nur in testing + bei Ubuntu enthalten)
 +  * [[http://jakarta.apache.org/jmeter/|Jmeter]] 
 +  * [[http://www.paessler.com/webstress|Webstress (Windows)]]
 +  * [[http://www.xenoclast.org/doc/benchmark/HTTP-benchmarking-HOWTO/|The Linux HTTP Benchmarking HOWTO]]
 +
 +===== X-Server =====
 +  * xengine
 +
 +
 +
 +===== Stresstests =====
 +  * zum belasten der CPU (prüfen von Systemstabilität) eignet sich cpuburn ganz gut.
 +  * contest: Kernelkompilationstests, eine ziemliche reale Aufgabe