Non sto scrivendo questo come una recensione negativa di AVA Hosting.
È semplicemente una delle mie giornate da sviluppatore: un server si comporta male, le spiegazioni più ovvie non tornano e, alla fine, Linux mostra cosa sta realmente succedendo.
Avevo un piccolo VPS KVM di AVA Hosting con:
1 vCPU
2 GB RAM
25 GB NVMeSul server girava un normale carico di produzione. Nginx era attivo. Il backend era attivo. C'era memoria disponibile. Il disco non era pieno.
Eppure il server non riusciva a stare al passo.
Ho quindi eseguito un'osservazione passiva di 60 secondi sotto normale traffico di produzione. Nessuno stress test, nessun flood HTTP sintetico e nessun benchmark del disco.
Il risultato:
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11Il numero decisivo era 32,73% di CPU steal. Da quel momento la diagnosi è cambiata completamente.
Perché mi ha sorpreso
AVA Hosting pubblicizza attualmente i propri VPS con la frase “Guaranteed resources — no sharing”. Le sue pagine parlano inoltre di allocazione vCPU fissa o dedicata e affermano che le prestazioni non dovrebbero essere influenzate da altri clienti. Nella documentazione Linux VPS, AVA va ancora oltre: il workload CPU-intensive di un altro tenant sullo stesso host non dovrebbe poter introdurre steal time nella tua istanza. Un'altra pagina afferma che il CPU steal viene eliminato a livello di hypervisor.
Sono affermazioni molto specifiche. Non era semplicemente una pagina con scritto 1 vCPU senza spiegare il modello di allocazione CPU. AVA pubblicizzava esplicitamente una protezione proprio dal tipo di CPU contention che Linux sembrava rilevare nella mia VM.
Cosa significa CPU steal
steal è una normale metrica CPU di Linux negli ambienti virtualizzati. Rappresenta il tempo in cui il guest aveva lavoro eseguibile, ma la CPU virtuale non stava effettivamente girando.
È diverso dal caso in cui la mia applicazione utilizzi semplicemente tutta la CPU disponibile. Se avessi visto circa 100% user/system, 0% steal e 0% idle, avrei concluso che il workload richiedeva semplicemente più potenza di calcolo.
Invece, circa un terzo del tempo CPU contabilizzato risultava steal.
Dall'interno del guest non posso vedere l'hypervisor di AVA. Non posso conoscere il carico del nodo fisico, il numero di VM vicine, la politica di CPU pinning o il rapporto di overcommit. Quello che posso vedere è ciò che Linux riportava alla mia VM: la vCPU smetteva ripetutamente di girare mentre c'era lavoro in attesa.
Non era un picco di un secondo
Un singolo campione CPU negativo non mi avrebbe convinto. Per questo ho misurato la macchina in modo continuo per 60 secondi. Non ho avviato intenzionalmente stress test, flood HTTP sintetici o benchmark del disco.
I campioni al secondo si presentavano ripetutamente così:
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00Verso la fine dell'osservazione, lo stesso schema era ancora presente:
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.00La media complessiva era:
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%Quindi non si trattava di una breve anomalia dello scheduler. Per gran parte del minuto, lo steal è rimasto intorno al 30% o oltre, mentre il CPU idle è rimasto a zero.
Per avere un riferimento, il 32,73% di un minuto equivale a circa 19,64 secondi. Non significa che il VPS sia rimasto congelato per 19,64 secondi consecutivi; significa che i piccoli intervalli in cui la vCPU non veniva schedulata si sono accumulati fino a circa quel valore.
Il backend non riusciva a recuperare
Il problema CPU era visibile anche a livello applicativo. Prima dell'osservazione, la listen queue del backend era:
Recv-Q: 168
Send-Q: 511Dopo 60 secondi:
Recv-Q: 166
Send-Q: 511I numeri precisi non sono importanti. Il punto è che la coda praticamente non si svuotava. L'applicazione ha avuto un minuto intero per recuperare, ma è rimasta indietro.
C'erano anche molte connessioni CLOSE-WAIT. Non attribuirei questo stato, da solo, all'host, perché può dipendere anche dalla gestione delle connessioni lato applicazione. Ma il quadro complessivo era coerente:
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not drainingIl server era vivo, ma non era sano.
RAM e disco non erano i colli di bottiglia evidenti
Ho controllato anche le cause più comuni. La memoria era:
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiBC'era ancora una quantità significativa di memoria disponibile e nessun evento OOM evidente che spiegasse il comportamento.
Il filesystem:
24 GB total
14 GB used
9.4 GB available
60% usedIl CPU I/O wait medio era 0.00%. Nel frattempo la CPU pressure rimaneva vicina al 99%, il load average era circa 3,5–4 su una VM con una sola vCPU e la runnable queue arrivava a 11.
Tutte le misurazioni indicavano la stessa direzione: la macchina era affamata di CPU, non chiaramente bloccata da RAM o storage.
La contraddizione con le parole di AVA
Questa è la parte che trovo più interessante.
AVA dichiara “Guaranteed resources — no sharing”. Dice che le prestazioni non dovrebbero essere influenzate da altri clienti. La documentazione Linux VPS afferma che un altro tenant non può introdurre steal time, e un'altra pagina dice che il CPU steal viene eliminato a livello di hypervisor.
Il mio VPS AVA mostrava:
Average CPU steal: 32.73%Dall'interno della VM non posso dimostrare esattamente perché sia successo. Non posso dimostrare overselling intenzionale, identificare uno specifico workload vicino o ricostruire la configurazione CPU dell'host AVA.
Non sto nemmeno sostenendo che tutti i VPS di AVA Hosting si comportino così. Ne ho testato uno.
Posso però dire che il comportamento che ho misurato è molto difficile da conciliare con quelle specifiche affermazioni sull'isolamento della CPU. Per questo articolo è sufficiente.
Perché non ho fatto upgrade
La risposta più ovvia sarebbe stata acquistare più vCPU.
Se il VPS avesse mostrato praticamente zero steal e la mia applicazione avesse semplicemente saturato un intero core, fare upgrade avrebbe avuto senso. Invece, circa un terzo della CPU osservata risultava steal.
Non volevo pagare per altre CPU virtuali prima di capire perché una parte così grande del tempo di esecuzione della prima vCPU fosse già segnalata come non disponibile. Ho quindi cancellato il VPS e chiesto un rimborso.
AVA ha rimborsato tutto rapidamente
Questa parte dell'esperienza è stata positiva.
AVA Hosting mi ha restituito l'intero importo. Il rimborso è stato gestito rapidamente e non hanno passato giorni a discutere le mie misurazioni CPU. Ho spiegato il problema, chiesto indietro i soldi e li hanno restituiti.
L'ho apprezzato.
Dalla mia esperienza emergono quindi due conclusioni distinte: il VPS che ho ricevuto aveva un serio problema di disponibilità CPU e AVA ha gestito correttamente il mio rimborso. Entrambe le cose sono vere.
Cosa mi porto via da questa esperienza
Non giudico più un VPS soltanto da una scheda tecnica come 1 vCPU / 2 GB RAM / NVMe / KVM. Questi numeri dicono cosa è stato provisionato, non quanto sarà prevedibile la disponibilità della CPU sotto carico reale.
Ora una delle prime cose che controllo su una nuova VM è:
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60La lezione più utile della mia esperienza con AVA Hosting non è che una vCPU sia necessariamente troppo poco. È che un processo in esecuzione, RAM disponibile e un disco apparentemente sano possono nascondere un problema completamente diverso.
Nel mio caso, Linux lo ha reso particolarmente evidente:
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%AVA Hosting pubblicizza risorse CPU senza condivisione e afferma che lo steal causato da workload vicini non dovrebbe verificarsi. Il mio VPS ha riportato qualcosa di diverso.
L'ho cancellato. AVA mi ha restituito tutto il denaro rapidamente e senza discutere.
E così si è conclusa questa giornata di debugging.