Hoe benchmark ik een VPS op de juiste manier?

Wat het benchmarken van een VPS inhoudt

Bij het benchmarken van een VPS meet u vier zaken: de snelheid van een enkele CPU-core, de geheugenbandbreedte van de machine, het aantal kleine willekeurige schijfbewerkingen per seconde en de doorvoersnelheid van de netwerkverbinding. Eén run van yabs.sh levert u al deze vier resultaten op in ongeveer tien minuten. Het interpreteren van de resultaten is het lastigste deel, omdat een VPS (virtual private server) fysieke hardware deelt met andere huurders. Hierdoor kan dezelfde machine om 03:00 uur een ander resultaat geven dan om 20:00 uur.

Het plan is om yabs.sh uit te voeren voor een snel overzicht en daarna de onderliggende tools handmatig te draaien. Door ze zelf uit te voeren, kunt u een flag aanpassen, het resultaat observeren en leren wat dat getal daadwerkelijk meet. Doe dit nadat de machine is geconfigureerd, niet daarvoor. De stappen in de eerste tien minuten op een nieuwe VPS hebben voorrang, omdat een machine die nog bezig is met de eerste reeks updates slecht scoort in benchmarks om redenen die niets met de hardware te maken hebben.

Inspecteer de machine voordat u deze meet

De helft van alle slechte benchmarks is het gevolg van een machine die de auteur niet begreep.

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

Hypervisor vendor: KVM staat voor volledige virtualisatie, wat betekent dat u uw eigen kernel draait. systemd-detect-virt met de uitvoer lxc of openvz duidt op containervirtualisatie: u deelt de kernel van de host en uw CPU- en geheugenlimieten zijn cgroup-instellingen (control group) in plaats van virtuele hardware. Op een cgroup v2-systeem kunt u de CPU-limiet direct uitlezen.

cat /sys/fs/cgroup/cpu.max

max 100000 betekent dat er geen quotum is. 200000 100000 betekent dat u 200000 microseconden aan CPU mag gebruiken in elke periode van 100000 microseconden, wat overeenkomt met een quotum van twee cores. Een abonnement dat wordt geadverteerd als 4 vCPU met een quotum van twee cores zal nooit presteren als vier cores, en geen enkele benchmark-tool geeft een melding die uitlegt waarom.

df -hT / is om een andere reden van belang: de kolom Type. Als hier overlay staat, bevindt u zich in een container en moet de onderstaande schijftest worden aangepast. Noteer dit nu.

Monitor steal time continu

Steal time is het aandeel van de tijd dat uw virtuele CPU klaar was om te draaien, maar de hypervisor de fysieke core aan een andere partij toewees. Dit is de meest bruikbare indicator om vast te stellen of een resultaat wordt beïnvloed door uw buren in plaats van door de hardware zelf.

vmstat 1 10

Lees de st-kolom aan de rechterkant. Een constante waarde van 0 of 1 is normaal. Aanhoudende waarden boven 5 betekenen dat de host op dat moment overgeboekt is; elk CPU-getal dat u in dat tijdsbestek noteert, is daardoor onbetrouwbaar zonder dat dit aan uw machine ligt. top toont hetzelfde cijfer als %st op de CPU-regel. Laat vmstat 1 draaien in een tweede SSH-sessie terwijl u benchmarks uitvoert en noteer het steal-cijfer naast elk resultaat.

Beginnen met yabs.sh

yabs.sh (Yet Another Bench Script) is een shell-script dat statische binaries voor fio, iperf3 en Geekbench downloadt, deze uitvoert en één samenvatting weergeeft. Het is de standaardtaal in discussies over VPS-benchmarks; een yabs-output is daarom de snelste manier om resultaten met anderen te vergelijken.

De officiële one-liner van het project ziet er als volgt uit.

curl -sL yabs.sh | bash

Hiermee wordt de inhoud van de URL direct naar een shell gepiped. Download het script, lees de inhoud en voer het vervolgens uit.

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

Flags plaatst u na -s -- wanneer u pipe-commando's gebruikt, of direct achter de bestandsnaam als u een lokale kopie uitvoert. De nuttige opties zijn: -f slaat de schijftest over, -i slaat de netwerktest over, -g slaat Geekbench over, -r beperkt het aantal iperf3-locaties tot twee, -j geeft de resultaten weer in JSON-formaat en -w results.json schrijft die JSON naar een bestand.

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

Er zijn twee zaken om te weten voor de eerste uitvoering. Geekbench uploadt uw resultaat en genereert een openbare browser.geekbench.com URL, waardoor iedereen met die link uw CPU-model en scores kan inzien. -g slaat deze test volledig over. Ten tweede verplaatst de iperf3-fase daadwerkelijk netwerkverkeer naar servers in verschillende regio's, wat meetelt voor uw maandelijkse bandbreedteverbruik. Op een 1 Gbit/s-verbinding kan een volledige netwerktest tientallen gigabytes verbruiken; gebruik daarom -r bij een kleine databundel en -i op een verbinding met een datalimiet.

Wat elk onderdeel van de yabs-output betekent

De disk-sectie voert fio uit met een 50/50 lees- en schrijfmix bij vier blokgroottes: 4k, 64k, 512k en 1m. Het rapporteert IOPS (input/output operations per second) en bandbreedte voor elk daarvan. De 4k-rij is de rij waar u op moet letten voor een database, een mailserver of elke andere toepassing die veel kleine schrijfacties uitvoert, omdat het meeste server-IO klein en verspreid is. De 1m-rij is de rij voor back-ups en video, waarbij u grote hoeveelheden data verplaatst.

De network-sectie voert iperf3 uit tegen publieke servers in verschillende regio's, in beide richtingen, met gebruik van parallelle streams. Beschouw een laag getal hier als een vraag in plaats van een antwoord, omdat publieke iperf3-servers gedeeld en vaak verzadigd zijn; een slecht resultaat kan dus aan de ontvangende kant liggen.

De Geekbench-sectie geeft een single core score en een multi core score. Single core voorspelt hoe snel één verzoek, één compilatie of één query wordt voltooid. Multi core geeft vooral aan hoeveel cores u daadwerkelijk heeft.

Schijf: voer fio zelf uit

fio (flexible IO tester) is de tool die onder de yabs-schijfsectie draait. Door deze direct aan te sturen, krijgen de flags hun werkelijke betekenis.

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

Een 4k random read-test met een queue depth van 32, op het bestandssysteem dat voor u relevant is:

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

De samenvattingsregel die u uit de output moet lezen, ziet er als volgt uit.

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

Daaronder print fio een clat percentiles-blok. Het 99.00e percentiel is de waarde die u moet noteren, omdat dit aangeeft hoe lang het traagste verzoek van de honderd moest wachten. Een gemiddelde latentie verbergt precies de vertragingen die een gebruiker opmerkt.

• --direct=1 opent het bestand met O_DIRECT, waardoor leesacties de kernel page cache omzeilen. Zonder deze optie wordt de tweede pass over een 2G-bestand op een machine met 8G RAM vanuit het geheugen geserveerd en rapporteert fio IOPS in de miljoenen. Dat getal is reëel, maar het is een geheugenwaarde.
• --ioengine=libaio verstuurt asynchrone verzoeken, waardoor --iodepth=32 er 32 tegelijk in de wachtrij kan houden. Met een synchrone engine zoals psync heeft een iodepth hoger dan 1 geen enkel effect, waardoor u slechts één verzoek tegelijk meet.
• --time_based --runtime=60 draait gedurende een vaste tijd van 60 seconden in plaats van een vaste hoeveelheid werk. Hierdoor krijgen een snelle en een trage schijf dezelfde tijd en blijft de vergelijking eerlijk.
• --size=2G stelt de grootte van het testbestand in. Houd deze groter dan elke cache in het pad en controleer eerst of u voldoende vrije ruimte heeft.

Random write gebruikt hetzelfde commando met --rw=randwrite. Voer dit afzonderlijk uit en verwijder daarna het bestand.

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

Gebruik voor een mix die dichter bij echt verkeer ligt --rw=randrw --rwmixread=70. Welk type opslag u gebruikt, heeft meer invloed op deze resultaten dan welke flag dan ook. Dit onderscheid wordt behandeld in het verschil tussen NVMe en SATA SSD-opslag op een VPS.

Wanneer fio stopt met Unknown error -1

Direct IO is niet op elk bestandssysteem beschikbaar. overlay, het bestandssysteem dat Docker standaard aan een container toewijst, en diverse netwerkbestandssystemen ondersteunen O_DIRECT niet. Hierdoor verstuurt libaio een verzoek dat de kernel niet kan voltooien en breekt fio af:

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

Voer eerst df -hT . uit. Als de kolom Type de waarde overlay aangeeft, wijs --filename dan naar een pad op fysieke opslag, zoals een bind-mounted volume, of voer fio uit op de host in plaats van in de container. Als fysieke opslag niet beschikbaar is, bewijst een gebufferde synchrone run in ieder geval dat het commando zelf correct is.

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

Wees eerlijk over wat die run inhoudt. Na de eerste pass bevindt het 256M bestand zich in de page cache, waardoor het IOPS-cijfer uw RAM beschrijft. Gebruik dit om te bevestigen dat fio is geïnstalleerd en de flags correct worden geparseerd. Citeer dit nooit als een schijfresultaat.

Waarom dd geen geschikte disk-benchmark is

dd komt veel voor in VPS-discussies en beantwoordt slechts één beperkte vraag.

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

Dit meet de sequentiële schrijfsnelheid met één thread en één verzoek in de wachtrij. Het is een redelijke basiscontrole. Het zegt echter niets over random IO, en niets over wat er gebeurt wanneer er 32 verzoeken tegelijk binnenkomen. Laat oflag=direct weg en de test meet vooral hoe snel uw kernel schrijfacties naar het geheugen accepteert; dit is de reden waarom dd-cijfers in forumberichten vaak absurd hoog zijn.

CPU: sysbench cpu

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

Het getal om in de gaten te houden is events per second. Voer de test eerst single-threaded uit. Dit getal bepaalt hoe snel één PHP-verzoek wordt afgehandeld of één compilatieklus wordt voltooid, en dit varieert het meest tussen hosts in dezelfde prijsklasse. Voer daarna de test uit met alle threads; dit laat zien of uw vCPU's aparte cores zijn of segmenten van één core.

Wees duidelijk over wat dit meet: sysbench cpu berekent herhaaldelijk priemgetallen met behulp van 64-bit integer-rekenkunde. Het belast de geheugenbandbreedte, vector-units of cache op geen enkele wijze die lijkt op een echte werklast. Het is daarom geschikt om twee hosts te vergelijken, maar ongeschikt om te voorspellen hoe uw applicatie zal presteren.

Ubuntu 24.04 levert sysbench 1.0.20, waarbij de testnaam als eerste wordt vermeld. Kopieert u een commando met --test=cpu uit een oud bericht, dan krijgt u WARNING: the --test option is deprecated. Scores van sysbench 0.4 en sysbench 1.0 zijn onderling niet vergelijkbaar. Meet uzelf daarom nooit af aan een gepubliceerd getal waarbij de versie niet wordt vermeld.

Geheugen: 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

Het resultaat wordt uitgedrukt in MiB/sec, waarbij leesacties op elke machine sneller verlopen dan schrijfacties. Houd --memory-block-size op 1M en zorg dat deze waarde identiek is op elke host die u vergelijkt. Bij 1K stort het getal in, omdat u de overhead per operatie duizend keer vaker betaalt. U meet dan de kosten van de lus in plaats van de geheugenbandbreedte. Dit is de meest voorkomende foutieve instelling bij gepubliceerde geheugenscores.

Netwerk: iperf3

De betrouwbare manier om doorvoersnelheid te testen is tegen een tweede machine die u beheert, omdat u dan weet wat beide uiteinden doen.

Aan de ontvangende kant:

iperf3 -s

Dit luistert op TCP 5201. Open de poort alleen voor het adres vanwaaruit u test en sluit deze zodra u klaar bent. Basis ufw firewallregels op een VPS behandelt de syntaxis.

Vanaf de VPS die wordt getest:

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

De eerste meet de upload vanaf de machine die wordt getest. -R draait de richting om, wat de download meet. -P 8 opent acht parallelle streams.

Voer zowel de enkele stream als de parallelle versie uit, omdat deze verschillende vragen beantwoorden. Eén TCP-verbinding kan slechts zoveel niet-bevestigde data bevatten als het venster toestaat; het plafond is dus grofweg de venstergrootte gedeeld door de round-trip time. Bij 80 ms latentie met een venster van 4 MB is dat plafond ongeveer 400 Mbit/s, ongeacht hoe snel de onderliggende verbinding is. Het cijfer van de enkele stream vertelt u wat één download zal behalen. Het parallelle cijfer vertelt u de capaciteit van de verbinding.

Houd uw bandbreedteverbruik in de gaten terwijl u dit doet. Dertig seconden op 1 Gbit/s verplaatst ongeveer 3,75 GB, en u zult dit meerdere keren in elke richting uitvoeren.

Referentiecijfers en hoe u uw eigen resultaten interpreteert

[
  {
    "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"
  }
]

Een lokaal NVMe-volume in gepubliceerde resultaten haalt doorgaans ongeveer 180,000 4k random read IOPS. Een lokale SATA SSD komt uit op ongeveer 90,000. Netwerkgekoppelde block storage, waarbij elk verzoek een netwerk passeert voordat het een schijf bereikt, ligt dichter bij 12,000, en een harde schijf haalt ongeveer 180, omdat deze voor elk random verzoek een fysieke leesarm moet verplaatsen.

Dit zijn typische gepubliceerde cijfers voor elke opslagklasse, geen metingen van één specifieke host. Gebruik ze voor één doel: controleren of uw eigen resultaat in de juiste grootteorde ligt. Als een abonnement dat als NVMe wordt verkocht in de benchmarks slechts enkele duizenden 4k IOPS haalt, controleer dan eerst of --direct=1 was ingeschakeld. Als dat zo is, dan is de opslag ofwel niet wat de productpagina beschrijft, of u deelt deze met een zeer actieve buurgebruiker.

Waarom één run geen benchmark is

Een enkel resultaat is een momentopname van één minuut op een gedeelde machine. Beschouw het als één steekproef.

• Voer elke test minimaal vijf keer uit, verspreid over verschillende uren en ten minste twee verschillende dagen. Noteer de mediaan en de spreiding. Een resultaat dat zonder spreiding wordt gepubliceerd, is een marketingcijfer.
• Registreer de steal time naast elke run. Verwerp runs waarbij st hoog was, of noteer in ieder geval dat dit het geval was.
• Voer de schijftest uit met twee verschillende looptijden. Veel abonnementen bieden een burst IOPS-toelage die in de loop van de tijd wordt aangevuld; een fio-run van 60 seconden meet dus de burst, terwijl --runtime=600 de ondergrens meet. De ondergrens is wat u krijgt op een slechte dag.
• Controleer of er niets anders draait. unattended-upgrades dat een apt-transactie start midden in een CPU-test kost u echte punten, en ps -e -o comm= | grep -E 'apt|dpkg' voor elke run kost een seconde.
• Wijzig slechts één variabele tegelijk. Verschillende toolversies, blokgroottes of thread-aantallen produceren getallen die niet met elkaar vergeleken kunnen worden, hoe vergelijkbaar ze er ook uitzien.

Wanneer u twee providers vergelijkt, voer de tests dan uit op hetzelfde uur van dezelfde dag. Anders heeft u enkel het tijdstip van de dag gemeten.

Benchmark uw eigen workload als laatste

Synthetische tools rangschikken machines. Alleen uw eigen workload vertelt u of een machine volstaat. Meet de tijd van de taken die u daadwerkelijk uitvoert.

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

Dit comprimeert enkele honderden megabytes, waardoor zowel de CPU als de schijf worden belast en de prestaties veranderen zodra een van beide wijzigt. De Removing leading / from member names waarschuwing is normaal. Beter nog is het om uw eigen build, uw traagste query of uw eigen paginarendering te timen. Een build die 4 minuten duurt op de ene host en 7 op de andere, beantwoordt de vraag, ongeacht wat Geekbench aangaf. Dit is ook de meting die u vertelt wanneer een krachtigere machine de extra kosten niet meer waard is. Dat is nuttige informatie voordat u leest wat een VPS daadwerkelijk per maand kost of de workload verplaatst naar een dedicated server.

FAQ

Waarom krijg ik telkens een ander benchmarkresultaat?

Een VPS deelt fysieke CPU, opslag en netwerk met andere huurders; uw resultaat hangt dus af van hun activiteit op dat moment. Voer vmstat 1 uit tijdens de test en bekijk de kolom st: een aanhoudende 'steal time' boven 5 betekent dat de host belast was en uw CPU-score laag uitvalt door factoren buiten uw machine. De oplossing is methodiek in plaats van tuning. Voer elke test vijf of meer keer uit op verschillende tijdstippen en rapporteer de mediaan samen met de spreiding.

Waarom rapporteert fio miljoenen IOPS?

Bijna altijd omdat --direct=1 ontbreekt. Zonder deze vlag leest fio via de kernel page cache; na de eerste run wordt een testbestand van 2G vanuit het RAM geserveerd en meet u de geheugenbandbreedte. Voeg --direct=1 toe en zorg dat het testbestand groter is dan elke cache in het pad. Als --direct=1 vervolgens faalt met err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, voer dan df -hT . uit: een Type van overlay ondersteunt geen O_DIRECT, dus wijs de test aan naar fysieke opslag.

Is yabs.sh op zichzelf voldoende?

Voor een eerste indruk wel. Het voert fio uit met vier blokgroottes, iperf3 in beide richtingen en Geekbench, en genereert een samenvatting die anderen kunnen lezen. Het is onvoldoende wanneer u wilt weten waarom een getal is wat het is, omdat u de vlaggen per test niet kunt variëren. Zodra een yabs-resultaat onjuist lijkt, reproduceert u dit direct met fio of sysbench en wijzigt u telkens één vlag.

Welk enkel getal voorspelt hoe mijn applicatie aanvoelt?

De single-core CPU-snelheid en de 4k random read latency, in die volgorde, voor de meeste web- en databaseworkloads. Doorvoersnelheden zien er indrukwekkend uit, maar zijn zelden doorslaggevend omdat een typisch verzoek klein is. Gebruik het 99e percentiel uit het fio clat percentiles-blok in plaats van het gemiddelde, aangezien de gebruiker juist het trage verzoek uit de honderd opmerkt.

Moet ik iets installeren voordat ik ga benchmarken?

fio, sysbench en iperf3 zitten in de Ubuntu- en Debian-archieven: sudo apt install -y fio sysbench iperf3. yabs.sh heeft alleen curl nodig, omdat het statische binaries downloadt voor alles wat ontbreekt. Verwijder elk testbestand wanneer u klaar bent; een 2G fio-bestand dat achterblijft op een 20G schijf leidt weken later tot een 'disk full'-melding voor iemand anders.