loadtest.appvon LoadFocus

Anleitungen

sysbench nutzen: CPU-, Festplatten- und MySQL-Benchmarks

6 Min. Lesezeit

sysbench ist ein quelloffenes Multithread-Benchmark-Tool auf Basis von LuaJIT, das Tests für CPU, Arbeitsspeicher, Datei-I/O, Threads und Mutexe mitbringt, dazu OLTP-Skripte für MySQL und PostgreSQL. Tests mit Daten folgen demselben Ablauf: prepare legt Testdateien oder Tabellen an, run führt den Benchmark für eine feste Zeit oder Zahl von Events aus, und cleanup entfernt die Daten wieder; die CPU- und Speichertests brauchen nur run. Gemessen wird eine einzelne Maschine oder ein einzelner Datenbankserver; wie sich Ihre Anwendung unter echtem Benutzer-Traffic verhält, verrät sysbench daher nicht.

Wir haben sysbench für diesen Leitfaden nicht selbst ausgeführt. Die Fakten stammen aus der README und dem Quellcode im Master-Branch auf GitHub, geprüft am 31. Oktober 2026; die Ratschläge sind unsere eigenen.

Themasysbench
LizenzGPLv2
Geschrieben inC, mit LuaJIT für Skripte
Letzte Version1.0.20 (24. April 2020)
Letzter Commit9. März 2025
Eingebaute Testscpu, memory, fileio, threads, mutex
DatenbankskripteAcht oltp_*-Skripte, bulk_insert, zwei select_random_*
DatenbanktreiberMySQL (Standard), PostgreSQL
PlattformenLinux, macOS; Windows über WSL

Wird sysbench noch gepflegt?

Nur noch wenig. Die letzte Version, 1.0.20, erschien im April 2020; der Master-Branch hat seitdem gelegentlich Commits erhalten, von denen keiner in einer Version erschienen ist, zuletzt im März 2025.

Die Version 1.0.20 ist auf den 24. April 2020 datiert. Die Commit-Historie zeigt Änderungen wie einen gleichverteilten Standard für --rand-type (2020), ein Upstream-LuaJIT (2023) und Unterstützung für MariaDB-Client-Bibliotheken (2023), danach vier Build-Commits am 9. März 2025 (geprüft am 31. Oktober 2026). Die Paket-Repositorys aus der README werden bei jeder Version aktualisiert, für diese Änderungen brauchen Sie also einen Build aus dem Quellcode.

Wie läuft ein sysbench-Test ab?

Sie geben einen Test und einen Befehl an: sysbench [options] [testname] [command]. Der Test ist ein eingebauter Test, ein mitgeliefertes Lua-Skript oder Ihr eigenes Skript, der Befehl meist prepare, run, cleanup oder help.

Laut README legt prepare die Dateien für fileio an oder füllt die Datenbank für die OLTP-Skripte, cleanup entfernt diese Daten, und sysbench <testname> help listet die Optionen eines Tests auf. Ein Festplattentest:

sysbench fileio --file-total-size=8G prepare
sysbench fileio --file-total-size=8G \
  --file-test-mode=rndrw --time=300 run
sysbench fileio --file-total-size=8G cleanup

Der fileio-Quellcode nennt die Modi seqwr, seqrewr, seqrd, rndrd, rndwr und rndrw, standardmäßig mit insgesamt 2 GB an Dateien. Dateien, die in den Arbeitsspeicher passen, kann der Page Cache bedienen; wählen Sie die Gesamtgröße also größer als den RAM, wenn Sie die Festplatte messen wollen.

Wie messen Sie CPU und Arbeitsspeicher mit sysbench?

Mit sysbench cpu run und sysbench memory run. Der CPU-Test meldet Events pro Sekunde, wobei ein Event jede Zahl bis zu einer Grenze auf Primzahleigenschaft prüft; der Speichertest meldet Operationen und übertragene MiB pro Sekunde.

sysbench cpu --cpu-max-prime=20000 \
  --threads=4 --time=60 run

Der CPU-Test setzt --cpu-max-prime standardmäßig auf 10000, und der Speichertest nimmt eine Blockgröße, eine Gesamtgröße, Lese- oder Schreiboperationen und sequenziellen oder zufälligen Zugriff entgegen (geprüft am 31. Oktober 2026). Vergleichen Sie nur Läufe mit identischen Einstellungen.

Wie testen Sie MySQL oder PostgreSQL mit sysbench?

Wählen Sie ein mitgeliefertes OLTP-Skript, füllen Sie die Tabellen mit prepare, führen Sie mit run Transaktionen aus mehreren Threads aus und löschen Sie die Tabellen danach mit cleanup. MySQL ist der Standardtreiber; PostgreSQL braucht --db-driver=pgsql und einen Build mit PostgreSQL-Unterstützung.

sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 prepare
sysbench oltp_read_write --mysql-host=10.0.0.5 \
  --mysql-user=sbtest --mysql-password=secret \
  --tables=10 --table-size=1000000 \
  --threads=16 --time=300 --report-interval=10 run

Das gemeinsame OLTP-Skript legt eine Tabelle mit 10.000 Zeilen an, sofern Sie nicht --tables und --table-size angeben. In oltp_read_write führt jede Transaktion 10 Punktabfragen, vier Bereichsabfragen, zwei Updates und ein Delete mit anschließendem Insert zwischen BEGIN und COMMIT aus (geprüft am 31. Oktober 2026). Machen Sie die Daten größer als den Buffer Pool des Servers, wenn das Ergebnis Lesezugriffe auf die Festplatte enthalten soll.

Welche sysbench-Optionen sind am wichtigsten?

--threads und --time bestimmen Größe und Dauer eines Laufs, --rate setzt eine Ziel-Eventrate, und --report-interval, --percentile und --histogram entscheiden, was Sie zu sehen bekommen.

  • --threads: Worker-Threads, standardmäßig 1.
  • --time: Sekunden, standardmäßig 10, 0 für keine Grenze. --events begrenzt die Zahl der Events, und beide Grenzen gelten, kombinieren Sie es also mit --time=0.
  • --warmup-time: läuft zuerst ohne Statistik, damit kalte Caches das Ergebnis nicht verzerren. Nur im Master-Branch: Version 1.0.20 kennt die Option nicht.
  • --rate: durchschnittliche Events pro Sekunde über alle Threads; 0, der Standard, heißt so schnell wie möglich.
  • --report-interval: Werte pro Intervall alle N Sekunden, um Hänger sichtbar zu machen.
  • --percentile: das gemeldete Latenz-Perzentil, standardmäßig 95.
  • --histogram: ein Latenz-Histogramm am Ende, definiert in sb_logger.c.

Nutzt sysbench ein geschlossenes oder ein offenes Lastmodell?

Standardmäßig ein geschlossenes: Eine feste Zahl von Threads startet jeweils das nächste Event, sobald das vorige endet, ein langsamer Server bekommt also weniger Events. Mit --rate kommen die Events nach eigenem Zeitplan an, was einem offenen Lastmodell näherkommt.

Unser Artikel zum offenen vs geschlossenen Lastmodell erklärt, warum das verändert, was ein Benchmark misst. Im Standardmodus verzögert ein Hänger außerdem die Events, die währenddessen gestartet wären, und diese Verzögerungen tauchen in den Latenzwerten nie auf: Coordinated Omission. Die Hauptquelldatei zeigt, dass --rate Events in exponentialverteilten Abständen in eine Warteschlange stellt, die Wartezeit jedes Events zu seiner Latenz addiert und mit dem Fehler “event queue is full” abbricht, wenn die Threads nicht mithalten (geprüft am 31. Oktober 2026).

Wie lesen Sie die Ausgabe von sysbench?

Beginnen Sie mit dem Durchsatz: Events pro Sekunde, bei den OLTP-Skripten Transaktionen und Abfragen pro Sekunde. Lesen Sie dann den Latenzblock in Millisekunden: Minimum, Durchschnitt, Maximum, das gewählte Perzentil (standardmäßig p95) und die Summe.

Version 1.0.20 gibt statt „Throughput“ einen Block „General statistics“ mit der Gesamtzeit und der Gesamtzahl der Events aus. Die Feldnamen stammen aus dem Code für den Datenbankbericht und der Hauptquelldatei im Master-Branch, hier ohne Werte:

SQL statistics:
    queries performed: read, write, other, total
    transactions, queries (N per sec.)
    ignored errors, reconnects (N per sec.)
Throughput:
    events/s (eps), time elapsed, total number of events
Latency (ms):
    min, avg, max, 95th percentile, sum
Threads fairness:
    events, execution time (avg/stddev)

Ein 95. Perzentil blendet das langsamste von je zwanzig Events aus. Setzen Sie --percentile=99 oder ergänzen Sie --histogram, wenn es auf die Ausreißer ankommt; unser Leitfaden zur Tail-Latenz erklärt, warum.

Wann ist sysbench das falsche Tool?

Wenn sich Ihre Frage um Ihre Anwendung dreht. Ein CPU-Wert zeigt, wie schnell eine Maschine Primzahlen prüft, und ein OLTP-Lauf misst den Datenbankserver mit den Tabellen und Abfragen von sysbench, ohne Ihr Schema, Ihren Connection Pool oder den Netzwerkweg.

  • Wählen Sie pgbench für Tests, die ganz bei PostgreSQL bleiben: Die PostgreSQL-Dokumentation beschreibt ein Standardszenario, das lose auf TPC-B basiert, dazu eigene Skriptdateien (geprüft am 31. Oktober 2026).
  • Wählen Sie HammerDB für Tests im Stil von TPC-C: Die Dokumentation behandelt den von TPC-C abgeleiteten Workload TPROC-C für SQL Server, Db2, Oracle, PostgreSQL, MariaDB und MySQL (geprüft am 31. Oktober 2026).
  • Wählen Sie JMeter mit seinem Sampler JDBC Request, um SQL und HTTP in einem Testplan zu mischen; laut Anleitung für Datenbank-Testpläne gehört die .jar-Datei des Treibers in den lib-Ordner von JMeter.

LoadFocus, der Herausgeber dieser Website, führt kein sysbench aus und kann sich selbst nicht mit MySQL oder PostgreSQL verbinden. LoadFocus führt JMeter-Testpläne und k6-Skripte aus 25 Cloud-Regionen gegen die Web- oder API-Schicht vor der Datenbank aus. Sinnvoll kombiniert: erst ein sysbench-Lauf, um den Datenbankserver zu dimensionieren, dann ein Lasttest der Anwendung, um zu sehen, ob echte Anfragen diese Grenze erreichen.

FAQ

Wird sysbench noch gepflegt? Nur wenig. Die letzte Version ist 1.0.20 vom 24. April 2020. Der Master-Branch hat seitdem gelegentlich Commits erhalten, keiner davon in einer Version, zuletzt am 9. März 2025.

Was bedeutet das 95. Perzentil in der Ausgabe von sysbench? Es ist die Latenz in Millisekunden, innerhalb derer 95 % der Events fertig wurden. 95 ist der Standardwert der Option --percentile, und Sie können einen anderen Wert wie 99 setzen.

Kann sysbench PostgreSQL testen? Ja. Die mitgelieferten OLTP-Skripte laufen mit --db-driver=pgsql gegen PostgreSQL, wenn sysbench mit PostgreSQL-Unterstützung gebaut wurde.

Kann LoadFocus sysbench ausführen? Nein. LoadFocus führt JMeter-Testpläne und k6-Skripte gegen Websites und APIs aus 25 Cloud-Regionen aus und verbindet sich nicht direkt mit MySQL oder PostgreSQL.

Weiterlesen

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.

LoadFocus team
Geschrieben vom LoadFocus-Team, den Leuten hinter einem Cloud-Lasttest-Dienst.