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, welche Speicherbandbreite das System erreicht, wie viele kleine zufällige Datenträgeroperationen der Speicher pro Sekunde verarbeitet und welchen Durchsatz die Netzwerkverbindung liefert. Ein Durchlauf von yabs.sh liefert CPU-, Datenträger- und Netzwerkergebnisse in etwa zehn Minuten. Für die Speicherbandbreite verwenden Sie den separaten Speichertest weiter unten. Die Ergebnisse richtig zu bewerten, ist schwieriger. Ein VPS teilt sich die physische Hardware mit anderen Mandanten. Deshalb kann dasselbe System um 03:00 einen Wert und um 20:00 einen deutlich anderen Wert liefern.

Führen Sie zunächst yabs.sh aus, um einen schnellen Überblick zu erhalten. Anschließend führen Sie die darunter beschriebenen Tools manuell aus. Nur so können Sie ein einzelnes Flag ändern, beobachten, wie sich der Wert verändert, und nachvollziehen, was dieser Wert tatsächlich misst. Führen Sie den Benchmark erst aus, wenn das System eingerichtet ist. Die Schritte in den ersten zehn Minuten auf einem neuen VPS kommen zuerst. Ein System, das noch die ersten Updates installiert, liefert aus Gründen, die nichts mit der Hardware zu tun haben, schlechte Benchmark-Ergebnisse.

Prüfen Sie die Maschine, bevor Sie sie messen

Die Hälfte jedes schlechten Benchmarks entsteht durch eine 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 also einen eigenen Kernel aus. Wenn systemd-detect-virt lxc oder openvz ausgibt, handelt es sich stattdessen um Container-Virtualisierung: Sie verwenden den Kernel des Hosts gemeinsam, und Ihre CPU- und Speicherlimits werden durch cgroup-Einstellungen (control groups) statt durch virtuelle Hardware festgelegt. Auf einem System mit cgroup v2 können Sie das CPU-Limit aus der cgroup Ihres Containers auslesen. Der folgende Pfad gilt, wenn diese cgroup unter /sys/fs/cgroup eingehängt ist.

cat /sys/fs/cgroup/cpu.max

max 100000 bedeutet, dass diese cgroup kein eigenes Quota hat. Übergeordnete cgroups können trotzdem ein Quota festlegen. 200000 100000 bedeutet, dass Sie in jedem Zeitraum von 100000 Mikrosekunden 200000 Mikrosekunden CPU-Zeit verwenden dürfen. Das entspricht einem Quota für zwei Kerne. Ein Tarif, der mit 4 vCPU und einem Quota von zwei Kernen beworben wird, erreicht niemals die Leistung von vier Kernen. Benchmark-Tools können diese Einschränkung erkennen: VoxelBench meldet CPU-Quotas und kennzeichnet eine gemeinsam genutzte oder gedrosselte CPU, wenn der Host deutlich mehr CPUs bereitstellt, als der Server verwenden darf.

df -hT / ist aus einem anderen Grund relevant: wegen der Spalte Type. Wenn dort overlay steht, befinden Sie sich in einem Container, und Ihre Festplattenwerte beschreiben den Speicher, der unter diesem Overlay liegt. Notieren Sie das jetzt.

Steal Time durchgehend überwachen

Steal Time ist der Zeitanteil, in dem Ihre virtuelle CPU unfreiwillig gewartet hat, weil der Hypervisor sie nicht eingeplant hat. Dieser Wert ist ein nützliches Signal für nicht verfügbare CPU-Zeit. Er unterscheidet jedoch nicht zwischen ausgelasteten Nachbarn und einer vom Provider durchgesetzten CPU-Quota.

vmstat 1 10

Lesen Sie die Spalte st auf der rechten Seite ab. Anhaltender Steal Time bedeutet, dass dem Gast CPU-Zeit nicht zur Verfügung stand. Ein Wert über 5% beweist jedoch nicht, dass der Host überbucht ist. Provider können die Durchsetzung einer CPU-Quota absichtlich als Steal Time ausweisen. top zeigt denselben Wert wie %st in der CPU-Zeile. Lassen Sie vmstat 1 während des Benchmarks in einer zweiten SSH-Sitzung laufen und notieren Sie den Steal-Wert neben jedem Ergebnis.

Start mit yabs.sh

yabs.sh (Yet Another Bench Script) ist ein Shell-Skript, das fio, iperf3 sowie Geekbench ausführt und eine Zusammenfassung ausgibt. Es verwendet fio und iperf3, falls diese bereits installiert sind, und lädt statische Binärdateien herunter, wenn dies nicht der Fall ist. Es ist die gängige Sprache für VPS-Benchmark-Diskussionen; daher ist eine yabs-Ausgabe der schnellste Weg, um Ergebnisse mit anderen zu vergleichen.

Die Einzeilenform des Projekts lautet wie folgt.

curl -sL yabs.sh | bash

Dies leitet den Inhalt, den die URL aktuell bereitstellt, direkt in eine Shell weiter. Laden Sie es herunter, lesen Sie es und führen Sie es dann aus.

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

Flags werden nach -s -- gesetzt, wenn Sie eine Pipe verwenden, oder direkt nach dem Dateinamen, wenn Sie eine lokale Kopie ausführen. Die nützlichen Optionen sind: -f überspringt den Festplattentest, -i überspringt den Netzwerktest, -g überspringt Geekbench, -r reduziert die Anzahl der iperf3-Standorte auf drei, -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

Zwei Dinge sind vor dem ersten Durchlauf zu beachten. Geekbench lädt Ihr Ergebnis hoch und gibt eine öffentliche URL unter browser.geekbench.com aus, sodass jeder, der diesen Link besitzt, Ihr CPU-Modell und die Ergebnisse einsehen kann. -g überspringt diesen Test vollständig. Zweitens überträgt die iperf3-Phase echten Datenverkehr zu Servern in verschiedenen Regionen, was auf Ihr monatliches Bandbreitenlimit angerechnet wird. Bei einer 1 Gbit/s-Anbindung kann eine vollständige Netzwerkphase mehrere zehn Gigabyte übertragen; verwenden Sie daher -r bei einem geringen Limit und -i bei einer volumenbasierten Anbindung.

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. Wenn fio seine allererste Anfrage mit gesetztem --direct=1 nicht ausführen kann, sollten Sie daher zuerst Direct IO als Ursache ausschließen. Der Fehler kann so aussehen:

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 zunächst df -hT . aus. Ein Type von overlay, dem Dateisystem, das Docker einem Container standardmäßig zuweist, ist allein nicht die Ursache. overlayfs reicht O_DIRECT an das darunterliegende Dateisystem weiter und verweigert es nur, wenn dieses Dateisystem kein Direct IO unterstützt. Daher funktioniert --direct=1 --ioengine=libaio auf einem Overlay über ext4 oder xfs. Wenn das Dateisystem unterhalb der Testdatei Direct IO tatsächlich nicht unterstützt, meldet fio dies normalerweise bereits beim Öffnen der Datei: fio: looks like your file system does not support direct=1/buffered=0. Verwenden Sie in diesem Fall --filename mit einem Pfad auf echtem lokalem Speicher, beispielsweise einem per Bind-Mount eingebundenen Volume, oder führen Sie fio auf dem Host statt im Container aus. Wenn kein Zugriff auf echten Speicher möglich ist, weist ein gepufferter synchroner Lauf zumindest nach, 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 Aussagekraft dieses Laufs korrekt ein. Nach dem ersten Durchlauf befindet sich die 256M-Datei im Page Cache. Der IOPS-Wert beschreibt daher den 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 kommt in vielen VPS-Threads vor und beantwortet eine eng begrenzte Frage.

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

Damit wird der sequenzielle Schreibdurchsatz mit einem Thread und einer ausstehenden Anfrage gemessen. Das ist ein sinnvoller Plausibilitätstest. Über zufällige E/A sagt er nichts aus. Ebenso wenig zeigt er, was passiert, wenn 32 Anfragen gleichzeitig eintreffen. Wenn Sie oflag=direct weglassen, laufen Schreibvorgänge über den Page Cache. conv=fdatasync sorgt jedoch weiterhin dafür, dass die Ausgabedaten vor Abschluss des Befehls auf dem Speichergerät gespeichert werden. Lassen Sie auch diese Option weg, misst das Ergebnis hauptsächlich, wie schnell Ihr Kernel Schreibvorgänge im Arbeitsspeicher entgegennimmt. Deshalb sind die in Forenbeiträgen genannten dd-Werte oft völlig unrealistisch.

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. Zwischen Hosts zum gleichen Preis unterscheidet er sich meist am stärksten. Führen Sie den Test anschließend mit allen Threads aus. Dadurch sehen Sie, wie sich der Durchsatz über die zugewiesenen vCPUs skaliert.

Beachten Sie, was dieser Test misst: sysbench cpu ermittelt wiederholt Primzahlen durch Probeteilung. Für jeden Kandidaten berechnet der Test zunächst eine Quadratwurzel mit doppelter Genauigkeit. Anschließend prüft er Teiler mit dem Modulo-Operator für 64-Bit-Ganzzahlen und vergleicht jeden Teiler mit dieser Gleitkomma-Grenze. Der Test kombiniert daher Ganzzahl- und Gleitkommaoperationen. Speicherbandbreite, Vektoreinheiten oder den Cache belastet er nicht in einer Weise, die einer realen Workload entspricht. Er eignet sich daher gut, um zwei Hosts zu vergleichen, aber schlecht, um das Laufzeitverhalten Ihrer Anwendung vorherzusagen.

Ubuntu 24.04 enthält sysbench 1.0.20. Bei dieser Version steht der Testname am Anfang. Wenn Sie einen Befehl mit --test=cpu aus einem älteren Beitrag übernehmen, 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.

Speicher: 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. Belassen Sie --memory-block-size auf 1M und verwenden Sie den Wert bei jedem verglichenen Host identisch. Bei 1K bricht der Wert ein, weil der Overhead pro Operation tausendmal häufiger anfällt. Dadurch messen Sie letztlich eher die Kosten der Schleife als die Speicherbandbreite. Dies ist das am häufigsten nicht übereinstimmende Flag in veröffentlichten Speichermesswerten.

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 Messwerte

[
  {
    "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 üblicherweise etwa 180,000 4k-IOPS bei zufälligen Lesezugriffen. Eine lokale SATA-SSD erreicht etwa 90,000. Bei netzwerkgebundenem Block-Storage, bei dem jede Anfrage das Netzwerk durchläuft, bevor sie einen Datenträger erreicht, liegt der Wert eher bei 12,000. Eine Festplatte mit rotierenden Magnetscheiben erreicht ungefähr 180, weil sie für jede zufällige Anfrage den Schreib-Lesekopf physisch bewegen muss.

Dies sind typische veröffentlichte Werte für die jeweilige Storage-Klasse, keine Messwerte eines einzelnen Hosts. Verwenden Sie sie nur für einen Zweck: Prüfen Sie, ob Ihr eigenes Ergebnis in derselben Größenordnung liegt. Wenn ein als NVMe beworbenes Angebot bei Benchmarks nur wenige tausend 4k-IOPS erreicht, prüfen Sie zunächst, ob --direct=1 aktiviert war. Wenn das der Fall war, überprüfen Sie die IOPS-Limits und Burst-Credits des Angebots sowie die Storage-Auslastung und die beworbene Hardware.

Warum ein einzelner Lauf kein Benchmark ist

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

• Führen Sie jeden Test mindestens fünfmal durch, verteilt über verschiedene Uhrzeiten und mindestens zwei verschiedene Tage. Speichern Sie den Median und die Streuung. Ein Ergebnis ohne Streuung ist eine Marketingzahl.
• Erfassen Sie neben jedem Lauf die Steal-Zeit. Behalten Sie Läufe bei, bei denen st hoch war, und untersuchen Sie, ob sie auf eine gemeinsame Ressourcennutzung oder das CPU-Limit des Plans zurückzuführen sind. Wenn Sie solche Läufe verwerfen, können Sie die tatsächlich verfügbare Leistung verbergen.
• Führen Sie den Festplattentest mit zwei Laufzeiten durch. Viele Pläne stellen ein Burst-IOPS-Kontingent bereit, das sich mit der Zeit wieder auffüllt. Weder ein 60-sekündiger fio-Lauf noch --runtime=600 garantiert jedoch, dass Sie das untere Leistungsniveau gemessen haben. AWS gp2-Credits können bei voller Balance mindestens 30 Minuten lang 3,000 IOPS aufrechterhalten, sodass beide Läufe die Burst-Leistung messen können. Prüfen Sie das Credit-Modell des Anbieters und überwachen Sie den Credit-Bestand, bevor Sie ein Ergebnis als dauerhaft verfügbare Leistung bezeichnen.
• Prüfen Sie, dass nichts anderes läuft. unattended-upgrades, das mitten in einem CPU-Test eine apt-Transaktion startet, kostet Sie reale Punkte, und ps -e -o comm= | grep -E 'apt|dpkg' vor jedem Lauf dauert eine Sekunde.
• Ändern Sie jeweils nur eine Variable. Unterschiedliche Tool-Versionen, Blockgrößen oder Thread-Anzahlen erzeugen Werte, die sich nicht vergleichen lassen, unabhängig davon, wie ähnlich sie aussehen.

Wenn Sie zwei Anbieter vergleichen, führen Sie die Tests zur gleichen Uhrzeit am gleichen Tag 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. Ihr Ergebnis hängt daher davon ab, was diese zu diesem Zeitpunkt tun. Führen Sie vmstat 1 während des Tests aus und lesen Sie die Spalte st: Eine dauerhaft erhöhte Steal Time erfasst nicht verfügbare CPU-Zeit. Sie kann jedoch sowohl auf eine vom Provider durchgesetzte CPU-Zuteilung als auch auf eine Auslastung des Hosts zurückgehen. Ein Wert über 5% beweist die Ursache nicht. Entscheidend ist die Messmethode, 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 bereitgestellt, und Sie haben die Speicherbandbreite gemessen. Fügen Sie --direct=1 hinzu. Die Testdatei muss größer sein als jeder Cache im Pfad. Wenn --direct=1 anschließend fehlschlägt, führen Sie df -hT . aus und prüfen Sie, worauf die Testdatei liegt. Ein Dateisystemtyp overlay ist allein kein Problem, weil overlayfs O_DIRECT an den darunterliegenden Speicher weiterleitet. Verschieben Sie die Testdatei nur dann auf lokalen physischen Speicher, wenn das darunterliegende Dateisystem direkte IO verweigert.

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. Außerdem gibt es eine Zusammenfassung aus, die andere Personen lesen können. Es reicht nicht mehr aus, wenn Sie wissen möchten, warum eine Zahl so ausfällt. Die Flags lassen sich nicht für jeden Test einzeln ändern. Sobald ein yabs-Ergebnis unplausibel wirkt, wiederholen Sie die Messung 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 das die Single-Core-CPU-Geschwindigkeit und die Latenz bei zufälligen 4k-Lesezugriffen, in dieser Reihenfolge. Durchsatzwerte wirken beeindruckend, entscheiden aber selten etwas, weil eine typische Anfrage klein ist. 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 Benchmark etwas installieren?

fio, sysbench und iperf3 sind in den Ubuntu- und Debian-Archiven enthalten: sudo apt install -y fio sysbench iperf3. yabs.sh wird in Bash ausgeführt und benötigt curl oder wget für Downloads sowie tar zum Entpacken von Geekbench. Ohne tar wird Geekbench übersprungen. Das Skript verwendet fio und iperf3, wenn sie installiert sind, und lädt statische Binärdateien herunter, wenn sie fehlen. Löschen Sie nach Abschluss alle Testdateien. Eine zurückgelassene 2G-fio-Datei auf einer 20G-Festplatte führt sonst Wochen später zu einem Alarm wegen voller Festplatte.