Prestazioni e affidabilità

Il steal time è la percentuale di tempo in cui la tua CPU virtuale era pronta a eseguire ma l'hypervisor ha dato il core fisico a qualcun altro. Appare come colonna "st" in top. Qualsiasi valore costantemente sopra il 2–3% significa che stai competendo per il core, ed è la causa usuale di picchi di latenza inspiegabili su un'istanza con vCPU condivise.

In ordine di probabilità: esaurimento della memoria che causa swap thrashing, saturazione dell'I/O del disco, CPU steal time su core condivisi, database non ottimizzato o latenza di rete verso i tuoi utenti. Controlla prima free -h e la colonna st in top — tra loro identificano la causa circa l'ottanta per cento delle volte.

Nell'ambito di una metropoli, sotto i 5 ms. All'interno di un continente, 10–40 ms. Attraverso l'Atlantico, 70–90 ms. Da Europa all'Asia, 150–200 ms. Percorsi antipodali, 250–320 ms. La luce nella fibra viaggia a circa due terzi della velocità della luce e i percorsi reali sono circa 1,35 volte la distanza del cerchio massimo, quindi circa 1 ms per 100 km per direzione è il minimo.

Un'istanza ben configurata con 2 vCPU / 4 GB serve un sito statico a milioni di visite mensili, un sito WordPress con cache a circa 300.000, e un'applicazione dinamica senza cache a forse 30.000. La variabile che domina è la cache, non l'hardware — la stessa istanza differisce di due ordini di grandezza a seconda di essa.

Misura le tre cose che realmente variano: CPU single-thread con sysbench, disco con fio a lettura/scrittura casuale 4K, e rete con iperf3 verso un endpoint noto. Esegui ciascuno più volte in ore diverse — un singolo benchmark misura quel minuto, non il server.

Circa cinque volte gli IOPS casuali — circa 500.000 versus 90.000 — e circa cinque volte la latenza inferiore, sotto 0,1 ms versus circa 0,5 ms. La velocità sequenziale è da sei a dieci volte superiore. Per applicazioni basate su database, il divario negli IOPS casuali è quello che senti realmente.

Il nostro SLA è del 99,99% per istanza, che consente circa 4,4 minuti di downtime al mese, e la disponibilità osservata nell'intera flotta negli ultimi dodici mesi è stata del 99,993%. Qualcosa di più richiede ridondanza che costruisci tu stesso: una singola macchina, per quanto buona, è un punto unico di guasto.

Indirettamente e misurabilmente. I motori di ricerca non classificano in base al paese del server, ma misurano la velocità della pagina, e la distanza è latenza. Un server a 200 ms dai tuoi utenti costa un punteggio Core Web Vitals reale. Usa una CDN se il tuo pubblico è globale; posiziona l'origine vicino al tuo pubblico se è regionale.

La protezione DDoS filtra il traffico di attacco a monte del tuo server, così le richieste legittime arrivano comunque. Deve essere sempre attiva per essere utile: la mitigazione che si attiva dopo l'inizio di un attacco ti ha già fatto cadere. OnionVPS include fino a 12 Tbps di pulizia L3/L4 a ogni livello, incluso il piano da $4.

L'isolamento è forte: KVM impone la separazione a livello hardware, e sfuggirvi è un exploit di livello di ricerca serio. Il rischio realistico non è l'ipervisore, ma la tua configurazione. SSH con password, software non aggiornato e un servizio aperto di cui ti sei dimenticato rappresentano essenzialmente tutti i compromessi nel mondo reale.

Una vCPU condivisa è pianificata rispetto ad altri tenant, quindi sotto contesa il tuo processo attende, visibile come steal time. Una vCPU dedicata è un thread fisico riservato a te con nessun altro pianificato su di esso. La condivisa va bene per lavori inattivi per la maggior parte del tempo; la dedicata è necessaria per qualsiasi cosa con un requisito di latenza.