Come fare un benchmark corretto di un VPS

Cosa significa eseguire un benchmark su un VPS

Per eseguire un benchmark su un VPS si misurano quattro aspetti: la velocità di esecuzione di un singolo core della CPU, la larghezza di banda della memoria, il numero di operazioni di I/O casuali di piccole dimensioni che lo storage può gestire ogni secondo e il throughput effettivo del collegamento di rete. Una singola esecuzione di yabs.sh fornisce tutti e quattro i valori in circa dieci minuti. La parte più difficile è interpretare il risultato, perché un VPS (virtual private server) condivide l'hardware fisico con altri tenant. Per questo, la stessa macchina può restituire un valore alle 03:00 e uno molto diverso alle 20:00.

Il piano è eseguire yabs.sh per ottenere una panoramica rapida, quindi eseguire manualmente gli strumenti che lo compongono. Eseguirli direttamente consente di modificare un flag, osservare come cambia il valore e capire che cosa misura realmente quel valore. Esegui questa procedura dopo aver configurato la macchina, non prima. I passaggi descritti in primi dieci minuti su un nuovo VPS vengono prima, perché un server che sta ancora applicando il primo ciclo di aggiornamenti produce risultati di benchmark poco attendibili per motivi che non dipendono dall'hardware.

Esamina la macchina prima di misurarne le prestazioni

La metà di ogni benchmark errato dipende da una macchina che l'autore non ha compreso.

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

Hypervisor vendor: KVM indica la virtualizzazione completa: esegui quindi un kernel autonomo. La stampa di lxc o openvz da parte di systemd-detect-virt indica invece la virtualizzazione tramite container: condividi il kernel dell'host e i limiti di CPU e memoria sono impostazioni cgroup (control group), non hardware virtuale. Su un sistema cgroup v2 puoi leggere direttamente il limite della CPU.

cat /sys/fs/cgroup/cpu.max

max 100000 indica che non è configurata alcuna quota. 200000 100000 indica che puoi usare 200000 microsecondi di CPU in ogni periodo di 100000 microsecondi, cioè una quota equivalente a due core. Un piano pubblicizzato come 4 vCPU con una quota di due core non otterrà mai risultati paragonabili a quattro core e nessuno strumento di benchmark stampa una riga che spieghi il motivo.

df -hT / è importante per un altro motivo: la colonna Type. Se contiene overlay, ti trovi all'interno di un container e il test del disco riportato di seguito richiede una modifica. Prendine nota ora.

Monitora continuamente lo steal time

Lo steal time è la quota di tempo in cui la CPU virtuale era pronta per l'esecuzione, ma l'hypervisor ha assegnato il core fisico a un altro guest. È il singolo indicatore più utile per capire se un risultato dipende dai vicini sullo stesso host anziché dall'hardware.

vmstat 1 10

Leggi la colonna st a destra. Un valore stabile pari a 0 o 1 è normale. Valori persistenti superiori a 5 indicano che in quel momento l'host è sovrallocato; di conseguenza, ogni valore della CPU registrato in quella finestra risulta più basso, senza che la causa sia un problema della tua macchina. top mostra lo stesso dato di %st nella riga della CPU. Mantieni vmstat 1 in esecuzione in una seconda sessione SSH durante il benchmark e annota il valore di steal accanto a ogni risultato.

Iniziare con yabs.sh

yabs.sh (Yet Another Bench Script) è uno script shell che scarica i binari statici di fio, iperf3 e Geekbench, li esegue e stampa un unico riepilogo. È il linguaggio comune nelle discussioni sui benchmark dei VPS, quindi un output di yabs è il modo più rapido per confrontare i risultati con altre persone.

Il comando su una riga fornito dal progetto è il seguente.

curl -sL yabs.sh | bash

Questo comando inoltra direttamente a una shell il contenuto attualmente restituito dall'URL. Scaricalo, leggilo e solo dopo eseguilo.

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

Quando usi una pipe, inserisci i flag dopo -s --. Se esegui una copia locale, inseriscili direttamente dopo il nome del file. I flag più utili sono: -f salta il test del disco, -i salta il test di rete, -g salta Geekbench, -r riduce a due le località di iperf3, -j stampa i risultati in formato JSON e -w results.json scrive il JSON in un file.

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

Prima della prima esecuzione devi sapere due cose. Geekbench carica il risultato e stampa un URL pubblico di browser.geekbench.com, quindi chiunque disponga di quel link può leggere il modello della CPU e i relativi punteggi. -g salta completamente questo test. Inoltre, la fase iperf3 genera traffico reale verso server situati in più regioni, che viene conteggiato nel limite mensile di banda. Su una connessione da 1 Gbit/s, una fase di rete completa può trasferire decine di gigabyte. Usa quindi -r con un limite ridotto e -i su una connessione a consumo.

Significato di ogni parte dell'output di yabs

La sezione del disco esegue fio con una combinazione bilanciata al 50% di letture e scritture, usando quattro dimensioni dei blocchi: 4k, 64k, 512k e 1m. Riporta gli IOPS (operazioni di input/output al secondo) e la larghezza di banda per ciascuna dimensione. La riga 4k è quella da considerare per un database, un server di posta o qualsiasi sistema che esegue molte scritture di piccole dimensioni, perché la maggior parte dell'IO dei server è costituita da operazioni piccole e distribuite. La riga 1m è invece quella utile per backup e video, che trasferiscono sequenze lunghe di byte.

La sezione di rete esegue iperf3 verso server pubblici in diverse regioni, in entrambe le direzioni e usando flussi paralleli. Considera un valore basso come un elemento da verificare, non come una conclusione, perché i server iperf3 pubblici sono condivisi e spesso saturi. Un risultato scarso può quindi dipendere dall'estremità remota.

La sezione Geekbench mostra un punteggio single core e un punteggio multi core. Il punteggio single core indica la velocità con cui termina una singola richiesta, compilazione o query. Il punteggio multi core indica soprattutto quanti core sono effettivamente disponibili.

Disco: eseguire fio direttamente

fio (flexible IO tester) è lo strumento utilizzato dalla sezione relativa ai dischi di yabs. Eseguirlo direttamente permette di interpretare correttamente le flag.

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

Un test di lettura casuale 4k con profondità della coda pari a 32, sul filesystem di interesse:

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

La riga di riepilogo da leggere nell'output è questa.

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

Subito sotto, fio stampa un blocco clat percentiles. Il percentile 99.00 è il valore da riportare, perché indica per quanto tempo ha atteso la richiesta più lenta su 100. La latenza media nasconde proprio i rallentamenti percepiti dall'utente.

• --direct=1 apre il file con O_DIRECT, quindi le letture bypassano la page cache del kernel. Senza questa opzione, la seconda passata su un file da 2G, in una macchina con 8G di RAM, viene servita dalla memoria e fio riporta IOPS nell'ordine dei milioni. Il valore è reale, ma misura la memoria.
• --ioengine=libaio invia richieste asincrone. Questo consente a --iodepth=32 di mantenerne 32 in elaborazione. Con un motore sincrono come psync, una iodepth superiore a 1 non ha alcun effetto: si misura una richiesta alla volta.
• --time_based --runtime=60 esegue il test per 60 secondi fissi anziché per una quantità di lavoro fissa. In questo modo un disco veloce e uno lento utilizzano lo stesso tempo effettivo e il confronto resta equo.
• --size=2G imposta la dimensione del file di test. Mantienila superiore a qualsiasi cache presente nel percorso e verifica prima di avere spazio libero sufficiente.

La scrittura casuale usa lo stesso comando con --rw=randwrite. Eseguila separatamente, quindi elimina il file.

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

Per un carico più simile al traffico reale, usa --rw=randrw --rwmixread=70. La classe di storage utilizzata incide sui risultati più di qualsiasi flag. Questa differenza è descritta in la differenza tra storage NVMe e SSD SATA su un VPS.

Quando fio si arresta con “Unknown error -1”

L'I/O diretto non è disponibile su tutti i filesystem. overlay, il filesystem che Docker assegna a un container per impostazione predefinita, e diversi filesystem di rete non supportano O_DIRECT. Di conseguenza, libaio invia una richiesta che il kernel non può completare e fio termina l'esecuzione:

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

Eseguire prima df -hT .. Se la colonna Type indica overlay, impostare --filename su un percorso che si trova su storage reale, ad esempio un volume montato tramite bind, oppure eseguire fio sull'host anziché nel container. Se non è possibile accedere allo storage reale, un'esecuzione sincrona con buffering consente almeno di verificare che il comando sia corretto.

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

Interpretare correttamente il risultato. Dopo il primo passaggio, il file da 256M si trova nella page cache, quindi il valore degli IOPS descrive la RAM. Usare questo test per verificare che fio sia installato e che i flag vengano analizzati correttamente. Non presentarlo mai come un risultato relativo al disco.

Perché dd non è un benchmark del disco

dd compare in molte discussioni sui VPS e risponde a una sola domanda specifica.

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

Misura il throughput di scrittura sequenziale con un thread e una sola richiesta in corso. È un controllo preliminare ragionevole. Non fornisce informazioni sull'I/O casuale né su cosa accade quando arrivano 32 richieste contemporaneamente. Senza oflag=direct misura soprattutto la velocità con cui il kernel accetta le scritture in memoria. Per questo i valori di dd riportati nei post dei forum sono spesso assurdi.

CPU: sysbench cpu

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

Il valore da considerare è events per second. Esegui prima il test con un solo thread. Questo valore determina la rapidità con cui viene completata una singola richiesta PHP o un singolo processo di compilazione e presenta le maggiori differenze tra host con lo stesso prezzo. Esegui poi il test con tutti i thread. In questo modo puoi verificare se le vCPU corrispondono a core distinti oppure a porzioni dello stesso core.

È importante chiarire che cosa misura questo test: sysbench calcola ripetutamente numeri primi usando l'aritmetica intera a 64 bit. Non sottopone la memoria, le unità vettoriali o la cache a un carico paragonabile a quello reale. È quindi utile per confrontare due host, ma non per prevedere il comportamento della tua applicazione.

Ubuntu 24.04 include sysbench 1.0.20, in cui il nome del test viene specificato per primo. Se copi da un vecchio articolo un comando con --test=cpu, ottieni WARNING: the --test option is deprecated. I punteggi di sysbench 0.4 e sysbench 1.0 non sono assolutamente confrontabili. Non confrontare quindi i tuoi risultati con un valore pubblicato se non ne viene indicata la versione.

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

Il risultato è espresso in MiB/sec e, su ogni macchina, le letture sono più veloci delle scritture. Mantieni --memory-block-size su 1M e usa esattamente lo stesso valore su ogni host confrontato. Con 1K il valore crolla, perché sostieni l'overhead per operazione mille volte più spesso. Di conseguenza misuri il costo del ciclo anziché la larghezza di banda della memoria. Questo è il flag con il valore più spesso non uniforme nei punteggi della memoria pubblicati.

Rete: iperf3

Il modo corretto per testare il throughput consiste nel farlo verso una seconda macchina sotto il proprio controllo, perché in questo modo si sa cosa stanno facendo entrambi gli endpoint.

Sul sistema remoto:

iperf3 -s

Il comando resta in ascolto sulla porta TCP 5201. Apri la porta solo per l'indirizzo da cui esegui il test e chiudila al termine. Regole di base del firewall ufw su un VPS descrive la sintassi.

Dal VPS sottoposto al test:

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

Il primo comando misura l'upload dalla macchina sottoposta al test. -R inverte la direzione e misura il download. -P 8 apre otto stream paralleli.

Esegui sia il test con un singolo stream sia quello parallelo, perché rispondono a domande diverse. Una singola connessione TCP può mantenere solo la quantità di dati non ancora confermati consentita dalla relativa finestra. Di conseguenza, il limite è approssimativamente pari alla dimensione della finestra divisa per il round-trip time. Con una latenza di 80 ms e una finestra di 4 MB, questo limite è di circa 400 Mbit/s, indipendentemente dalla velocità del collegamento sottostante. Il valore del singolo stream indica la velocità che otterrà un singolo download. Il valore del test parallelo indica la capacità del collegamento.

Controlla il consumo previsto dal tuo piano di banda durante il test. Trenta secondi a 1 Gbit/s trasferiscono circa 3.75 GB e dovrai eseguire il test più volte in entrambe le direzioni.

Valori di riferimento e interpretazione dei propri risultati

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

Un volume NVMe locale raggiunge in genere circa 180,000 IOPS in lettura casuale 4k nei risultati pubblicati. Un SSD SATA locale si attesta intorno a 90,000. Lo storage a blocchi collegato tramite rete, in cui ogni richiesta attraversa la rete prima di raggiungere un disco, si avvicina a 12,000, mentre un disco magnetico raggiunge circa 180, perché deve spostare una testina fisica per ogni richiesta casuale.

Questi sono valori pubblicati tipici per ciascuna classe di storage, non misurazioni effettuate su un singolo host. Usali solo per verificare che il tuo risultato sia dello stesso ordine di grandezza. Se un piano venduto come NVMe registra nei benchmark poche migliaia di IOPS in lettura casuale 4k, verifica innanzitutto che --direct=1 fosse attivo. Se lo era, lo storage non corrisponde a quanto descritto nella pagina del prodotto oppure lo stai condividendo con un vicino molto occupato.

Perché una sola esecuzione non è un benchmark

Un singolo risultato è un'istantanea di un minuto su una macchina condivisa. Consideralo un solo campione.

• Esegui ogni test almeno cinque volte, distribuite in ore diverse e in almeno due giorni diversi. Conserva la mediana e la dispersione. Un risultato pubblicato senza dispersione è un dato di marketing.
• Registra lo steal time accanto a ogni esecuzione. Scarta le esecuzioni in cui st era elevato oppure, come minimo, annota che lo era.
• Esegui il test del disco con due durate. Molti piani offrono una disponibilità burst di IOPS che si ricostituisce nel tempo, quindi un'esecuzione di fio di 60 secondi misura il burst, mentre --runtime=600 misura il livello minimo. Il livello minimo è ciò che ottieni in una giornata sfavorevole.
• Verifica che non sia in esecuzione nient'altro. unattended-upgrades avviare una transazione apt durante un test della CPU ti fa perdere punti reali, mentre ps -e -o comm= | grep -E 'apt|dpkg' prima di ogni esecuzione richiede un secondo.
• Modifica una sola variabile alla volta. Versioni diverse degli strumenti, dimensioni dei blocchi o numero di thread producono valori che non possono essere confrontati, per quanto simili possano sembrare.

Quando confronti due provider, esegui i test alla stessa ora dello stesso giorno. In caso contrario, hai misurato l'ora del giorno.

Esegui per ultimo il benchmark del tuo carico di lavoro

Gli strumenti sintetici classificano le macchine. Solo il tuo carico di lavoro indica se una macchina è sufficiente. Misura il tempo dell'attività che esegui realmente.

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

Questa operazione comprime alcune centinaia di megabyte, quindi utilizza contemporaneamente CPU e disco e cambia quando cambia uno dei due. L'avviso Removing leading / from member names è normale. Meglio ancora, misura il tempo della tua build, della query più lenta che esegui o del rendering della tua pagina. Una build che richiede 4 minuti su un host e 7 sull'altro risolve la questione, indipendentemente dal risultato di Geekbench. Questa è anche la misura che indica quando una macchina più potente non vale più il costo aggiuntivo, un'informazione utile prima di leggere quanto costa realmente un VPS al mese o di spostare il carico di lavoro su un server dedicato.

FAQ

Perché ottengo un risultato diverso dal benchmark ogni volta che lo eseguo?

Un VPS condivide CPU, storage e rete fisici con altri tenant, quindi il risultato dipende da ciò che stanno facendo in quel momento. Esegui vmstat 1 durante il test e leggi la colonna st: uno steal time sostenuto superiore a 5 indica che l'host era sotto carico e che il punteggio della CPU è basso per motivi esterni alla tua macchina. La soluzione consiste nel metodo, non nel tuning. Esegui ogni test almeno cinque volte in orari diversi, quindi comunica la mediana insieme alla dispersione.

Perché fio segnala milioni di IOPS?

Quasi sempre perché manca --direct=1. Senza questa opzione, fio legge attraverso la page cache del kernel; dopo il primo passaggio, quindi, un file di test da 2G viene fornito dalla RAM e in realtà hai misurato la larghezza di banda della memoria. Aggiungi --direct=1 e mantieni il file di test più grande di qualsiasi cache presente nel percorso. Se --direct=1 non riesce con err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, esegui df -hT .: un Type di overlay non supporta O_DIRECT, quindi indirizza il test verso lo storage reale.

yabs.sh è sufficiente da solo?

Per una prima valutazione, sì. Esegue fio con quattro dimensioni di blocco, iperf3 in entrambe le direzioni e Geekbench, quindi stampa un riepilogo leggibile anche da altre persone. Non è più sufficiente quando vuoi capire perché un valore è quello che è, perché non puoi variare i flag per ogni test. Quando un risultato di yabs sembra errato, riproducilo direttamente con fio o sysbench e modifica un flag alla volta.

Quale singolo valore predice la reattività della mia applicazione?

Per la maggior parte dei carichi web e dei database, la velocità della CPU su un singolo core e la latenza delle letture casuali 4k, in quest'ordine. I valori di throughput sono impressionanti, ma raramente determinanti, perché una richiesta tipica è piccola. Riporta il 99° percentile del blocco clat percentiles di fio invece della media, perché è la richiesta lenta su cento che l'utente nota.

Devo installare qualcosa prima di eseguire il benchmark?

fio, sysbench e iperf3 sono tutti disponibili negli archivi Ubuntu e Debian: sudo apt install -y fio sysbench iperf3. yabs.sh richiede soltanto curl, perché scarica binari statici per tutto ciò che manca. Elimina tutti i file di test al termine: un file fio da 2G lasciato su un disco da 20G può attivare, dopo alcune settimane, un avviso di disco pieno.