VPS richtig benchmarken: yabs.sh, fio und iperf3

Was es bedeutet, einen VPS zu benchmarken

Beim Benchmarking eines VPS messen Sie vier Werte: wie schnell ein einzelner CPU-Kern arbeitet, wie hoch die Speicherbandbreite des Systems ist, wie viele kleine zufällige Datenträgeroperationen der Speicher pro Sekunde verarbeitet und welchen Durchsatz die Netzwerkverbindung liefert. Ein Durchlauf von yabs.sh liefert alle vier Werte in etwa zehn Minuten. Die Ergebnisse richtig zu lesen, ist schwieriger, da ein VPS (virtueller privater Server) die physische Hardware mit anderen Mandanten teilt. Daher kann dasselbe System um 03:00 einen Wert und um 20:00 einen deutlich anderen Wert melden.

Führen Sie zunächst yabs.sh aus, um schnell einen Überblick zu erhalten. Danach führen Sie die zugrunde liegenden Werkzeuge manuell aus. So können Sie ein einzelnes Flag ändern, beobachten, wie sich der Wert verändert, und verstehen, was dieser Wert tatsächlich misst. Führen Sie dies erst durch, nachdem das System eingerichtet ist. Die Schritte in den ersten zehn Minuten auf einem neuen VPS kommen zuerst, da ein System, das noch die erste Runde von Updates installiert, aus Gründen, die nichts mit der Hardware zu tun haben, schlechte Benchmark-Ergebnisse liefert.

Prüfen Sie die Maschine, bevor Sie sie messen

Die Hälfte jedes schlechten Benchmarks entsteht auf einer Maschine, die der Autor nicht verstanden hat.

nproc
lscpu | grep -E 'Model name|Hypervisor|Thread'
free -h
df -hT /
uname -r
systemd-detect-virt

Hypervisor vendor: KVM bedeutet vollständige Virtualisierung. Sie führen daher Ihren eigenen Kernel aus. systemd-detect-virt mit lxc oder openvz bedeutet dagegen Container-Virtualisierung. Sie verwenden den Kernel des Hosts gemeinsam mit anderen. Die Begrenzungen für CPU und Arbeitsspeicher sind dann cgroup-Einstellungen (control group) und keine virtuelle Hardware. Auf einem System mit cgroup v2 können Sie die CPU-Begrenzung direkt auslesen.

cat /sys/fs/cgroup/cpu.max

max 100000 bedeutet, dass kein Kontingent festgelegt ist. 200000 100000 bedeutet, dass Sie in jedem Zeitraum von 100000 Mikrosekunden 200000 Mikrosekunden CPU-Zeit verwenden dürfen. Das entspricht einem Kontingent von zwei Kernen. Ein Tarif, der mit 4 vCPU und einem Kontingent von zwei Kernen beworben wird, erreicht nie die Leistung von vier Kernen. Kein Benchmark-Tool gibt eine Zeile aus, die den Grund dafür nennt.

df -hT / ist aus einem anderen Grund wichtig: wegen der Spalte Type. Wenn dort overlay steht, befinden Sie sich in einem Container. Der unten beschriebene Festplattentest muss dann angepasst werden. Merken Sie sich das jetzt.

Steal-Zeit kontinuierlich überwachen

Steal-Zeit ist der Zeitanteil, in dem Ihre virtuelle CPU zur Ausführung bereit war, der Hypervisor den physischen Kern aber einem anderen Prozess zugewiesen hat. Dies ist das wichtigste einzelne Signal dafür, dass ein Ergebnis auf Ihre Nachbarn und nicht auf die Hardware zurückzuführen ist.

vmstat 1 10

Lesen Sie rechts die Spalte st. Ein gleichbleibender Wert von 0 oder 1 ist normal. Anhaltende Werte über 5 bedeuten, dass der Host zu diesem Zeitpunkt überbucht ist. Daher ist jeder CPU-Wert, den Sie in diesem Zeitraum erfassen, ohne Verschulden Ihrer Maschine zu niedrig. top zeigt denselben Wert wie %st in der CPU-Zeile. Lassen Sie vmstat 1 während des Benchmarks in einer zweiten SSH-Sitzung weiterlaufen und notieren Sie den Steal-Wert neben jedem Ergebnis.

Mit yabs.sh beginnen

yabs.sh (Yet Another Bench Script) ist ein Shell-Skript. Es lädt statische Binärdateien von fio, iperf3 und Geekbench herunter, führt sie aus und gibt eine Zusammenfassung aus. Das Skript dient als gemeinsame Grundlage für VPS-Benchmarkdiskussionen. Eine yabs-Ausgabe ist daher die schnellste Möglichkeit, Ergebnisse mit anderen zu vergleichen.

Die vom Projekt vorgesehene Einzeilenform lautet:

curl -sL yabs.sh | bash

Damit wird alles, was die URL aktuell liefert, direkt an eine Shell weitergeleitet. Laden Sie das Skript herunter, lesen Sie es, und führen Sie es anschließend aus.

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

Beim Weiterleiten stehen die Flags hinter -s --. Beim Ausführen einer lokalen Kopie stehen sie direkt hinter dem Dateinamen. Die wichtigen Flags sind: -f überspringt den Festplattentest, -i überspringt den Netzwerktest, -g überspringt Geekbench, -r reduziert die Anzahl der iperf3-Standorte auf zwei, -j gibt die Ergebnisse als JSON aus, und -w results.json schreibt dieses JSON in eine Datei.

bash yabs.sh -r -w yabs-run1.json

Vor dem ersten Lauf sollten Sie zwei Dinge wissen. Geekbench lädt Ihr Ergebnis hoch und gibt eine öffentliche URL unter browser.geekbench.com aus. Jeder, der diesen Link besitzt, kann Ihr CPU-Modell und Ihre Punktzahlen einsehen. -g überspringt diesen Test vollständig. Außerdem überträgt die iperf3-Phase echten Netzwerkverkehr zu Servern in mehreren Regionen. Dieser Datenverkehr wird auf Ihr monatliches Bandbreitenlimit angerechnet. Über eine Verbindung mit 1 Gbit/s kann eine vollständige Netzwerkphase mehrere zehn Gigabyte übertragen. Verwenden Sie daher -r bei einem kleinen Bandbreitenlimit und -i bei einer kostenpflichtig nach Datenvolumen abgerechneten Verbindung.

Was die einzelnen Teile der yabs-Ausgabe bedeuten

Der Festplattenabschnitt führt fio mit einer Lese-/Schreibverteilung von 50/50 bei vier Blockgrößen aus: 4k, 64k, 512k und 1m. Er gibt für jede Blockgröße die IOPS (Eingabe-/Ausgabeoperationen pro Sekunde) und die Bandbreite an. Für eine Datenbank, einen Mailserver oder jede Anwendung mit vielen kleinen Schreibvorgängen ist die Zeile für 4k maßgeblich, weil der Großteil der Server-E/A aus kleinen, verstreuten Zugriffen besteht. Die Zeile für 1m ist für Backups und Video relevant, bei denen lange Bytefolgen übertragen werden.

Der Netzwerkabschnitt führt iperf3 gegen öffentliche Server in mehreren Regionen und in beiden Richtungen mit parallelen Datenströmen aus. Betrachten Sie einen niedrigen Wert hier als Frage und nicht als endgültige Aussage, weil öffentliche iperf3-Server gemeinsam genutzt werden und häufig ausgelastet sind. Ein schlechtes Ergebnis kann daher durch die Gegenstelle verursacht werden.

Der Geekbench-Abschnitt enthält einen Single-Core-Wert und einen Multi-Core-Wert. Der Single-Core-Wert zeigt, wie schnell eine einzelne Anfrage, ein einzelner Kompiliervorgang oder eine einzelne Abfrage abgeschlossen wird. Der Multi-Core-Wert zeigt hauptsächlich, wie viele Kerne Ihnen tatsächlich zugewiesen wurden.

Disk: fio selbst ausführen

fio (flexible IO tester) ist das Werkzeug hinter dem Disk-Abschnitt von yabs. Wenn Sie fio direkt ausführen, werden die Flags verständlich.

sudo apt update && sudo apt install -y fio sysbench iperf3

Ein Test mit zufälligen 4k-Lesezugriffen bei einer Warteschlangentiefe von 32 auf dem Dateisystem, das Sie tatsächlich verwenden:

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

Die aus der Ausgabe abzulesende Zusammenfassungszeile sieht so aus.

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

Darunter gibt fio einen clat percentiles-Block aus. Das 99.00-Perzentil ist die relevante Angabe, weil es zeigt, wie lange die langsamste von 100 Anfragen gewartet hat. Eine durchschnittliche Latenz verdeckt genau die Verzögerungen, die Benutzer bemerken.

• --direct=1 öffnet die Datei mit O_DIRECT, sodass Lesezugriffe den Page Cache des Kernels umgehen. Ohne diese Option wird der zweite Durchlauf über eine 2G-Datei auf einem Rechner mit 8G RAM aus dem Speicher bedient, und fio meldet IOPS im Millionenbereich. Dieser Wert ist real, aber er beschreibt den Speicher.
• --ioengine=libaio übergibt asynchrone Anfragen. Dadurch kann --iodepth=32 32 Anfragen gleichzeitig bearbeiten. Bei einer synchronen Engine wie psync hat eine iodepth über 1 überhaupt keine Wirkung. Sie messen dann jeweils nur eine Anfrage.
• --time_based --runtime=60 lässt den Test 60 Sekunden lang laufen, statt eine feste Arbeitsmenge zu verarbeiten. Dadurch erhalten eine schnelle und eine langsame Festplatte dieselbe reale Laufzeit, und der Vergleich bleibt fair.
• --size=2G legt die Größe der Testdatei fest. Lassen Sie sie größer als jeden Cache im Datenpfad sein, und prüfen Sie vorher, ob genügend freier Speicherplatz vorhanden ist.

Zufällige Schreibzugriffe verwenden denselben Befehl mit --rw=randwrite. Führen Sie den Test separat aus und löschen Sie anschließend die Datei.

fio --name=randwrite4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randwrite --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f ./fio-testfile

Für eine Mischung, die dem realen Netzwerkverkehr näherkommt, verwenden Sie --rw=randrw --rwmixread=70. Die verwendete Speicherklasse beeinflusst diese Ergebnisse stärker als jedes Flag. Diese Unterschiede werden in dem Unterschied zwischen NVMe- und SATA-SSD-Speicher auf einem VPS erläutert.

Wenn fio mit Unknown error -1 beendet wird

Direct IO ist nicht auf jedem Dateisystem verfügbar. overlay, das Dateisystem, das Docker einem Container standardmäßig zuweist, und mehrere Netzwerkdateisysteme unterstützen O_DIRECT nicht. Daher übermittelt libaio eine Anforderung, die der Kernel nicht abschließen kann, und fio bricht ab:

fio: io_u error on file ./fio-testfile: Unknown error -1: read offset=0, buflen=4096
fio: pid=1234, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1

Führen Sie zuerst df -hT . aus. Wenn die Spalte Type den Wert overlay enthält, setzen Sie --filename auf einen Pfad auf echtem Speicher, zum Beispiel auf ein per Bind-Mount eingebundenes Volume, oder führen Sie fio auf dem Host statt im Container aus. Wenn kein Zugriff auf echten Speicher möglich ist, bestätigt ein gepufferter synchroner Lauf zumindest, dass der Befehl selbst korrekt ist.

fio --name=randread4k-buffered --filename=./fio-testfile --size=256M --bs=4k \
  --rw=randread --ioengine=psync --direct=0 --numjobs=1 \
  --runtime=15 --time_based --group_reporting
rm -f ./fio-testfile

Ordnen Sie die Ergebnisse dieses Laufs korrekt ein. Nach dem ersten Durchlauf befindet sich die 256M-Datei im Page Cache. Der IOPS-Wert beschreibt daher Ihren Arbeitsspeicher. Verwenden Sie den Lauf, um zu bestätigen, dass fio installiert ist und die Flags korrekt verarbeitet werden. Geben Sie ihn niemals als Datenträgerergebnis aus.

Warum dd kein Festplatten-Benchmark ist

dd wird in vielen VPS-Threads verwendet und beantwortet eine eng begrenzte Frage.

dd if=/dev/zero of=./ddtest bs=1M count=1024 oflag=direct conv=fdatasync
rm -f ./ddtest

Damit messen Sie den sequenziellen Schreibdurchsatz mit einem Thread und einer ausstehenden Anfrage. Das ist ein sinnvoller Plausibilitätstest. Über zufällige IO-Vorgänge sagt der Test nichts aus. Ebenso wenig zeigt er, was passiert, wenn 32 Anfragen gleichzeitig eintreffen. Wenn Sie oflag=direct entfernen, messen Sie größtenteils, wie schnell Ihr Kernel Schreibvorgänge in den Speicher übernimmt. Deshalb sind die in Forenbeiträgen genannten dd-Werte oft unrealistisch hoch.

CPU: sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

Der relevante Wert ist events per second. Führen Sie den Test zuerst mit einem Thread aus. Dieser Wert bestimmt, wie schnell eine einzelne PHP-Anfrage abgeschlossen wird oder ein einzelner Kompilierungsvorgang endet. Außerdem unterscheidet er sich bei Hosts zum gleichen Preis am stärksten. Führen Sie den Test danach mit allen Threads aus. Damit sehen Sie, ob Ihre vCPUs separate Kerne oder Anteile eines einzelnen Kerns sind.

Beachten Sie, was dieser Test misst: sysbench ermittelt wiederholt Primzahlen mit ganzzahliger 64-Bit-Arithmetik. Der Test belastet weder die Speicherbandbreite noch Vektoreinheiten oder den Cache in einer Weise, die einer realen Arbeitslast ähnelt. Er eignet sich daher gut zum Vergleichen zweier Hosts, aber schlecht zur Vorhersage, wie Ihre Anwendung ausgeführt wird.

Ubuntu 24.04 enthält sysbench 1.0.20. Bei dieser Version steht der Testname an erster Stelle. Wenn Sie einen Befehl mit --test=cpu aus einem älteren Beitrag kopieren, erhalten Sie WARNING: the --test option is deprecated. Ergebnisse von sysbench 0.4 und sysbench 1.0 sind überhaupt nicht vergleichbar. Vergleichen Sie Ihre Werte daher niemals mit einer veröffentlichten Zahl, bei der die Version nicht angegeben ist.

Arbeitsspeicher: sysbench memory

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write --threads=1 run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read --threads=1 run

Das Ergebnis wird in MiB/sec angegeben. Auf jedem Rechner sind Lesevorgänge schneller als Schreibvorgänge. Belassen Sie --memory-block-size bei 1M und verwenden Sie auf allen verglichenen Hosts denselben Wert. Bei 1K bricht der Wert ein, weil der Overhead pro Vorgang tausendmal häufiger anfällt. Dadurch messen Sie eher die Kosten der Schleife als die Speicherbandbreite. Dies ist das Flag, das bei veröffentlichten Speicherwerten am häufigsten nicht übereinstimmt.

Netzwerk: iperf3

Die zuverlässige Methode zur Durchsatzmessung ist ein Test gegen einen zweiten Rechner, den Sie kontrollieren. Dann wissen Sie, was an beiden Enden passiert.

Auf der Gegenstelle:

iperf3 -s

Der Server wartet damit auf TCP 5201. Öffnen Sie den Port nur für die Adresse, von der aus Sie testen, und schließen Sie ihn nach Abschluss des Tests wieder. Grundlegende ufw-Firewallregeln auf einem VPS beschreibt die Syntax.

Auf dem zu testenden VPS:

iperf3 -c 203.0.113.10 -t 30
iperf3 -c 203.0.113.10 -t 30 -R
iperf3 -c 203.0.113.10 -t 30 -P 8

Der erste Befehl misst den Upload vom zu testenden Rechner. -R kehrt die Richtung um und misst den Download. -P 8 öffnet acht parallele Datenströme.

Führen Sie sowohl den Test mit einem Datenstrom als auch die Variante mit parallelen Datenströmen aus. Beide beantworten unterschiedliche Fragen. Eine TCP-Verbindung kann nur so viele nicht bestätigte Daten übertragen, wie ihr Fenster zulässt. Die Obergrenze entspricht daher ungefähr der Fenstergröße geteilt durch die Round-Trip-Zeit. Bei 80 ms Latenz und einem 4 MB großen Fenster liegt diese Obergrenze bei etwa 400 Mbit/s, unabhängig davon, wie schnell die zugrunde liegende Verbindung ist. Der Wert für einen einzelnen Datenstrom zeigt, welchen Durchsatz ein einzelner Download erhält. Der Wert für parallele Datenströme zeigt die Kapazität der Verbindung.

Überwachen Sie währenddessen Ihr Bandbreitenkontingent. Dreißig Sekunden mit 1 Gbit/s übertragen etwa 3.75 GB. Sie führen den Test in jeder Richtung mehrmals aus.

Referenzwerte und die Einordnung Ihrer Ergebnisse

[
  {
    "device": "Local NVMe",
    "iops_4k_read": "180,000"
  },
  {
    "device": "Local SATA SSD",
    "iops_4k_read": "90,000"
  },
  {
    "device": "Network block",
    "iops_4k_read": "12,000"
  },
  {
    "device": "Spinning disk",
    "iops_4k_read": "180"
  }
]

Ein lokales NVMe-Volume erreicht in veröffentlichten Ergebnissen normalerweise etwa 180,000 4k-Random-Read-IOPS. Eine lokale SATA-SSD erreicht etwa 90,000. Netzwerkgebundener Blockspeicher, bei dem jede Anforderung ein Netzwerk durchläuft, bevor sie einen Datenträger erreicht, liegt eher bei 12,000. Eine Festplatte mit rotierenden Magnetscheiben erreicht ungefähr 180, weil sie für jede zufällige Anforderung einen physischen Lesekopf bewegen muss.

Dies sind typische veröffentlichte Werte für die jeweilige Speicherkategorie, keine Messungen von einem einzelnen Host. Verwenden Sie sie nur für einen Zweck: Prüfen Sie, ob Ihr eigenes Ergebnis in der richtigen Größenordnung liegt. Wenn ein als NVMe angebotenes Produkt bei einem Benchmark nur wenige tausend 4k-IOPS erreicht, prüfen Sie zuerst, ob --direct=1 aktiviert war. Falls ja, entspricht der Speicher entweder nicht der Beschreibung auf der Produktseite, oder Sie teilen ihn mit einem stark ausgelasteten Nachbarn.

Warum ein Durchlauf kein Benchmark ist

Ein einzelnes Ergebnis ist eine Momentaufnahme von einer Minute auf einem gemeinsam genutzten Rechner. Behandeln Sie es als eine Stichprobe.

• Führen Sie jeden Test mindestens fünfmal durch, verteilt auf verschiedene Stunden und mindestens zwei verschiedene Tage. Bewahren Sie den Median und die Streuung auf. Ein Ergebnis ohne Streuung ist eine Marketingzahl.
• Zeichnen Sie neben jedem Durchlauf die Steal-Zeit auf. Verwerfen Sie Durchläufe, bei denen st hoch war, oder vermerken Sie dies zumindest.
• Führen Sie den Festplattentest mit zwei Laufzeiten durch. Viele Tarife bieten ein Burst-IOPS-Kontingent, das sich mit der Zeit wieder auffüllt. Daher misst ein 60 Sekunden langer fio-Durchlauf den Burst, während --runtime=600 das Minimum misst. Das Minimum ist die Leistung, die Sie an einem schlechten Tag erhalten.
• Stellen Sie sicher, dass nichts anderes ausgeführt wird. unattended-upgrades, das mitten in einem CPU-Test eine apt-Transaktion startet, kostet Sie messbare Punkte, und ps -e -o comm= | grep -E 'apt|dpkg' vor jedem Durchlauf dauert eine Sekunde.
• Ändern Sie jeweils nur eine Variable. Unterschiedliche Tool-Versionen, Blockgrößen oder Thread-Anzahlen erzeugen Zahlen, die nicht miteinander vergleichbar sind, unabhängig davon, wie ähnlich sie aussehen.

Wenn Sie zwei Anbieter vergleichen, führen Sie die Tests am selben Wochentag zur selben Uhrzeit durch. Andernfalls haben Sie die Tageszeit gemessen.

Messen Sie zuletzt Ihre eigene Arbeitslast

Synthetische Tools bewerten Maschinen. Nur Ihre eigene Arbeitslast zeigt, ob eine Maschine ausreicht. Messen Sie die Zeit für die Tätigkeit, die Sie tatsächlich ausführen.

time tar -czf /tmp/bench.tgz /usr/share
rm -f /tmp/bench.tgz

Dabei werden einige hundert Megabyte komprimiert. Dadurch werden CPU und Datenträger gemeinsam belastet, und das Ergebnis ändert sich, sobald sich eine der beiden Komponenten ändert. Die Warnung Removing leading / from member names ist normal. Noch besser ist es, die Zeit für Ihren eigenen Build, Ihre langsamste Abfrage oder das Rendern Ihrer eigenen Seite zu messen. Wenn ein Build auf einem Host 4 Minuten und auf einem anderen 7 Minuten dauert, ist die Frage unabhängig von Geekbench beantwortet. Diese Messung zeigt Ihnen außerdem, ab wann sich eine leistungsfähigere Maschine finanziell nicht mehr lohnt. Das sollten Sie wissen, bevor Sie erfahren, was ein VPS tatsächlich pro Monat kostet oder die Arbeitslast auf einen dedizierten Server verschieben.

FAQ

Warum erhalte ich bei jeder Ausführung ein anderes Benchmark-Ergebnis?

Ein VPS teilt sich CPU, Speicher und Netzwerk mit anderen Mandanten. Daher hängt Ihr Ergebnis davon ab, was diese zu diesem Zeitpunkt tun. Führen Sie während des Tests vmstat 1 aus und lesen Sie die Spalte st: Ein dauerhaftes Steal Time über 5 bedeutet, dass der Host ausgelastet war. Ihre CPU-Wertung ist dann aus Gründen niedrig, die außerhalb Ihrer Maschine liegen. Entscheidend ist die Methode, nicht die Optimierung. Führen Sie jeden Test mindestens fünfmal zu unterschiedlichen Uhrzeiten aus. Geben Sie anschließend den Median zusammen mit der Streuung an.

Warum meldet fio Millionen IOPS?

Fast immer fehlt --direct=1. Ohne diese Option liest fio über den Page Cache des Kernels. Nach dem ersten Durchlauf wird eine 2G-Testdatei daher aus dem RAM bedient. Gemessen wurde dann die Speicherbandbreite. Fügen Sie --direct=1 hinzu. Die Testdatei muss größer als jeder Cache im Pfad sein. Wenn --direct=1 anschließend mit err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1 fehlschlägt, führen Sie df -hT . aus: Ein Type von overlay unterstützt O_DIRECT nicht. Richten Sie den Test stattdessen auf echten Speicher.

Reicht yabs.sh allein aus?

Für einen ersten Überblick ja. Das Skript führt fio mit vier Blockgrößen, iperf3 in beide Richtungen und Geekbench aus. Es gibt eine Zusammenfassung aus, die andere Personen lesen können. Es reicht nicht mehr aus, sobald Sie wissen möchten, warum eine Zahl so ausfällt. Die Flags lassen sich für die einzelnen Tests nicht ändern. Sobald ein yabs-Ergebnis falsch wirkt, reproduzieren Sie es direkt mit fio oder sysbench. Ändern Sie dabei jeweils nur ein Flag.

Welche einzelne Zahl sagt voraus, wie sich meine Anwendung anfühlen wird?

Für die meisten Web- und Datenbank-Workloads sind die CPU-Geschwindigkeit eines einzelnen Kerns und die Latenz bei zufälligen 4k-Lesezugriffen entscheidend, in dieser Reihenfolge. Durchsatzwerte wirken beeindruckend, entscheiden aber selten etwas. Eine typische Anfrage ist klein. Geben Sie das 99. Perzentil aus dem fio-Block clat percentiles statt des Durchschnitts an. Die eine langsame Anfrage von hundert bemerkt der Benutzer.

Muss ich vor dem Benchmarking etwas installieren?

fio, sysbench und iperf3 sind in den Ubuntu- und Debian-Archiven enthalten: sudo apt install -y fio sysbench iperf3. yabs.sh benötigt nur curl. Fehlende Komponenten werden als statische Binärdateien heruntergeladen. Löschen Sie nach Abschluss jede Testdatei. Eine zurückgelassene 2G-fio-Datei auf einem 20G-Datenträger löst sonst Wochen später den Disk-full-Alarm aus.