Come fare correttamente il benchmark di un VPS

Cosa significa eseguire un benchmark su un VPS

Per eseguire un benchmark su un VPS, misurate 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 completa ogni secondo e il throughput fornito dal collegamento di rete. Un'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 un valore molto diverso alle 20:00.

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

Esaminare la macchina prima di misurarla

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, quindi viene eseguito il proprio kernel. La stampa di lxc o openvz da parte di systemd-detect-virt indica invece la virtualizzazione basata su container: si condivide il kernel dell'host e i limiti di CPU e memoria sono impostazioni cgroup (control group), non hardware virtuale. In un sistema cgroup v2 è possibile leggere direttamente il limite della CPU.

cat /sys/fs/cgroup/cpu.max

max 100000 indica che non esiste alcuna quota. 200000 100000 indica che è possibile utilizzare 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 ne spieghi il motivo.

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

Monitorare il tempo sottratto per tutta la durata

Il tempo sottratto è la parte di tempo in cui la CPU virtuale era pronta per l'esecuzione, ma l'hypervisor ha assegnato il core fisico a un altro sistema. È il singolo indicatore più utile per capire se un risultato dipende dai vicini anziché dall'hardware.

vmstat 1 10

Leggere la colonna st a destra. Un valore costante pari a 0 o 1 è normale. Valori persistenti superiori a 5 indicano che in quel momento l'host è sovraccarico, quindi ogni valore della CPU registrato durante quell'intervallo è basso senza che la macchina abbia problemi. top mostra lo stesso valore di %st nella riga della CPU. Lasciare vmstat 1 in esecuzione in una seconda sessione SSH durante il benchmark e annotare il valore del tempo sottratto accanto a ogni risultato.

Introduzione a 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 altri utenti.

La forma su una sola riga prevista dal progetto è questa.

curl -sL yabs.sh | bash

Questo comando inoltra direttamente a una shell tutto ciò che l'URL restituisce in quel momento. Scarica lo script, leggilo e poi 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 --. Quando esegui una copia locale, inseriscili direttamente dopo il nome del file. Quelli utili sono: -f salta il test del disco, -i salta il test di rete, -g salta Geekbench, -r riduce a due le località iperf3, -j stampa i risultati in formato JSON e -w results.json scrive quel JSON in un file.

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

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

Significato di ogni parte dell'output di yabs

La sezione del disco esegue fio con una combinazione 50/50 di letture e scritture, usando quattro dimensioni di blocco: 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 più importante per un database, un server di posta o qualsiasi sistema che esegua molte scritture di piccole dimensioni, perché la maggior parte dell'IO dei server è costituita da operazioni piccole e distribuite. La riga 1m è quella utile per i backup e i video, dove si trasferiscono sequenze lunghe di byte.

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

La sezione Geekbench fornisce 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 hai realmente a disposizione.

Disco: esegui fio direttamente

fio (flexible IO tester) è lo strumento utilizzato dalla sezione disco di yabs. Eseguirlo direttamente permette di interpretare correttamente i flag.

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

Un test di lettura casuale da 4k, con una profondità della coda di 32, sul filesystem che interessa effettivamente:

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 è simile a questa.

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

Sotto questa riga, 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. Una latenza media nasconde proprio i rallentamenti che l'utente percepisce.

• --direct=1 apre il file con O_DIRECT, quindi le letture ignorano la page cache del kernel. Senza questa opzione, il secondo passaggio su un file da 2G, su una macchina con 8G di RAM, viene servito dalla memoria e fio riporta IOPS nell'ordine dei milioni. Il valore è reale, ma misura la memoria.
• --ioengine=libaio invia richieste asincrone. Questo permette a --iodepth=32 di mantenerne 32 in esecuzione. Con un motore sincrono come psync, una iodepth superiore a 1 non produce alcun effetto: si misura una richiesta alla volta.
• --time_based --runtime=60 esegue il test per 60 secondi fissi invece di una quantità di lavoro fissa. In questo modo un disco veloce e uno lento utilizzano lo stesso tempo reale e il confronto resta corretto.
• --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 utilizza 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. La differenza è descritta in la differenza tra storage NVMe e SSD SATA su un VPS.

Quando fio si interrompe 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 si interrompe:

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 nello 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 I/O bufferizzato dimostra almeno che il comando è 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 questo risultato. Dopo il primo passaggio, il file da 256M rimane nella cache delle pagine, quindi il valore degli IOPS descrive la RAM. Usarlo per verificare che fio sia installato e che i flag vengano analizzati correttamente. Non presentarlo mai come un risultato del disco.

Perché dd non è un benchmark dei dischi

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

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

Misura la velocità di scrittura sequenziale con un thread e una sola richiesta in corso. È un controllo preliminare ragionevole. Non dice nulla sull'IO casuale né su ciò che accade quando arrivano 32 richieste contemporaneamente. Se si rimuove oflag=direct, misura soprattutto la velocità con cui il kernel accetta le scritture in memoria. Per questo i valori di dd citati 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. Eseguire prima il test con un singolo thread. Questo valore determina la rapidità con cui una richiesta PHP viene completata o un processo di compilazione termina, e varia maggiormente tra host con lo stesso prezzo. Eseguire poi il test con tutti i thread. In questo modo si verifica se le vCPU corrispondono a core separati o a porzioni dello stesso core.

È importante chiarire cosa misura questo test: sysbench CPU calcola ripetutamente numeri primi usando l'aritmetica intera a 64 bit. Non sottopone la larghezza di banda della 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 dell'applicazione.

Ubuntu 24.04 include sysbench 1.0.20, in cui il nome del test viene specificato per primo. Se si copia un comando con --test=cpu da un articolo precedente, si ottiene WARNING: the --test option is deprecated. I punteggi di sysbench 0.4 e sysbench 1.0 non sono assolutamente comparabili. Non confrontare quindi i propri risultati con un valore pubblicato che non indica la versione utilizzata.

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 risultano più veloci delle scritture. Mantieni --memory-block-size su 1M e impostalo allo stesso modo 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. Questa è l'opzione configurata più spesso in modo non uniforme nei punteggi della memoria pubblicati.

Rete: iperf3

Il modo corretto per testare la velocità di trasferimento consiste nell'eseguire il test verso una seconda macchina sotto il tuo controllo, perché in questo modo sai cosa sta facendo ciascuna delle due estremità.

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 flussi paralleli.

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

Controlla il limite di traffico incluso nel tuo piano mentre esegui questi test. Trenta secondi a 1 Gbit/s trasferiscono circa 3.75 GB e dovrai eseguire il test diverse 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 nei risultati pubblicati raggiunge in genere circa 180,000 IOPS di lettura casuale 4k. Un SSD SATA locale si attesta intorno a 90,000. Lo storage a blocchi collegato alla 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é sposta una testina fisica per ogni richiesta casuale.

Questi sono valori pubblicati tipici per ogni classe di storage, non misurazioni eseguite su un singolo host. Usali per un solo scopo: verificare che il tuo risultato sia dello stesso ordine di grandezza. Se un piano venduto come NVMe restituisce nei benchmark poche migliaia di IOPS 4k, verifica prima 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 impegnato.

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 il tempo di steal accanto a ogni esecuzione. Scarta le esecuzioni in cui st era elevato oppure, come minimo, annota questo dato.
• Esegui il test del disco con due durate. Molti piani offrono una quota di IOPS burst che si reintegra nel tempo, quindi un'esecuzione di fio di 60 secondi misura il burst, mentre --runtime=600 misura il livello minimo. Il livello minimo è quello che ottieni nelle giornate peggiori.
• 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, indipendentemente dalla loro somiglianza.

Quando confronti due provider, esegui i test alla stessa ora dello stesso giorno. Altrimenti avrai 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

Questo comando comprime alcune centinaia di megabyte, quindi usa insieme 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 o del rendering della tua pagina. Una build che richiede 4 minuti su un host e 7 su un altro risolve la questione, indipendentemente dal risultato di Geekbench. Questa è anche la misurazione che indica quando una macchina più potente non vale più il costo aggiuntivo. È utile saperlo 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 fisica, storage e rete con altri tenant. Il risultato dipende quindi 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, quindi il punteggio della CPU è basso per motivi esterni alla tua macchina. La soluzione è usare un metodo coerente, non modificare la configurazione. Esegui ogni test almeno cinque volte in ore diverse, quindi riporta la mediana insieme alla dispersione.

Perché fio indica 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 servito dalla RAM e stai misurando 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 che altri possono leggere. Non è più sufficiente quando vuoi sapere perché un valore è quello che è, perché non puoi modificare i flag per ogni test. Quando un risultato di yabs sembra errato, riproducilo direttamente con fio o sysbench e modifica un solo flag alla volta.

Quale singolo valore prevede la reattività della mia applicazione?

Per la maggior parte dei carichi di lavoro web e database, la velocità su un singolo core e la latenza di lettura casuale 4k, in quest'ordine. I valori di throughput sembrano impressionanti, ma raramente sono 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 è quella che l'utente nota.

Devo installare qualcosa prima di eseguire il benchmark?

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