Overcommitment della CPU: come rallenta i server virtuali

Sovraccarico della CPU rallenta i server virtuali perché l'hypervisor alloca più vCPU di quanti siano i core fisici, con conseguenti tempi di attesa. Mostro le cause, i valori reali misurati come il CPU Ready Time e le regolazioni specifiche che utilizzo per mantenere stabili le prestazioni dei VPS.

Punti centrali

Prima di approfondire l'argomento, classificherò gli aspetti più importanti e delineerò i tipici fraintendimenti. Molti operatori confondono l'alto utilizzo con l'efficienza, anche se le code determinano i tempi di risposta. I dettagli dello scheduler determinano se le applicazioni funzionano bene o si bloccano. Riassumo gli argomenti principali su cui mi baserò nei capitoli successivi. L'elenco serve come riferimento compatto per prendere decisioni rapide.

• scheduler e il time slicing determinano la modalità di allocazione delle vCPU.
• CPU pronta visualizza i tempi di attesa e segnala tempestivamente i colli di bottiglia.
• Ospiti SMP (vCPU multiple) aumentano l'overhead e la latenza.
• Diritti di proprietà e il monitoraggio mantengono i picchi di carico gestibili.
• Selezione del fornitore senza overbooking garantisce prestazioni costanti.

Cosa significa tecnicamente overcommitment della CPU?

Impegno eccessivo Ciò significa che alloco più core virtuali di quanti ne abbia fisicamente l'host e mi affido allo scheduler dell'hypervisor. KVM o VMware allocano il tempo di calcolo tramite il time slicing, che è poco appariscente in condizioni di basso carico e sembra consentire un'alta densità. In caso di carico parallelo, tuttavia, i tempi di attesa aumentano perché diverse vCPU richiedono tempo di calcolo contemporaneamente e lo scheduler deve programmarle una dopo l'altra. Red Hat avverte che le macchine virtuali SMP, in particolare con molte vCPU, perdono molte prestazioni non appena la somma delle vCPU supera in modo significativo i core fisici [1]. Gli esperti di VMware quantificano questo fenomeno attraverso il CPU Ready Time: 1000 ms di attesa per vCPU corrispondono a una perdita di prestazioni di circa 5%, cumulativamente per core [3].

Perché i server virtuali sono rallentati

Code sono il motivo principale per cui i server virtuali rallentano in caso di overbooking, anche se l'utilizzo della CPU sembra elevato. Una vCPU può essere eseguita solo quando un core fisico è libero; fino a quel momento, il CPU Ready aumenta e l'applicazione attende. Con diverse macchine virtuali con picchi paralleli, l'effetto è esacerbato perché sono tutte „pronte per l'esecuzione“ e lo scheduler può lavorare solo a fette di tempo. In particolare, i carichi di lavoro critici dal punto di vista della latenza, come i database, le API o i backend dei negozi, reagiscono in modo sensibile, poiché ogni ulteriore cambio di contesto e ogni ritardo innesca effetti a catena. Si osservano quindi timeout, tempi di risposta instabili e una crescente varianza che irrita notevolmente gli utenti.

Variabili misurate: CPU Ready, Steal & Co.

Indicatori come CPU Ready, Co-Stop e Steal Time mi indicano subito se l'overcommitment sta influenzando la mia VM. La CPU Ready nelle metriche dell'hypervisor dovrebbe rimanere in media ben al di sotto di 5%; se il valore sale a percentuali a due cifre, il throughput diminuisce sensibilmente [3]. Co-Stop segnala che le macchine virtuali SMP non possono essere pianificate contemporaneamente, il che rallenta il multi-threading. Nei guest Linux, leggo Steal Time, che mostra quanto tempo l'host sta sottraendo alla mia VM; ne ho spiegato il background e la messa a punto in modo accessibile qui: Tempo di appropriazione della CPU. Se si combinano questi tre segnali, è possibile riconoscere per tempo i colli di bottiglia e impedire che i problemi di latenza si ripercuotano sull'applicazione.

Esempio reale: Quando il 5:1 supera il limite

Pratica batte la teoria non appena si mescolano i carichi di lavoro reali: Un host con 4 core fisici e 5 VM con 4 vCPU ciascuna non presenta problemi quando è inattivo, ma mostra tempi di attesa enormi sotto carico. Se una VM avvia l'elaborazione di immagini o i backup, lo scheduler dà la priorità, ma le VM rimanenti accumulano valori di CPU-ready di oltre 2000 ms, il che significa una perdita di prestazioni di circa 10% per core [3]. In un test documentato di SQL server, il throughput è sceso da 25.200 transazioni al minuto a meno della metà [3] quando è stato attivato il funzionamento in background. Anche l'I/O rallenta indirettamente, perché le vCPU vengono preemplificate durante gli accessi ai dispositivi a blocchi e le pipeline si bloccano. Si verifica quindi un misto di picchi elevati, code lunghe e jitter inaspettato nei tempi di risposta.

Rischi speciali per gli ospiti SMP

Macchine SMP-VM con molte vCPU richiedono slot coordinati su diversi core fisici, il che aumenta lo sforzo di schedulazione e i tempi di attesa. Più vCPU ha una singola VM, più spesso attende che tutte le fette di tempo richieste si riuniscano. Red Hat consiglia quindi di privilegiare diverse macchine virtuali più piccole con poche vCPU invece di eseguire singoli guest „wide-gauge“ [1]. Un rapporto di overcommit di 10:1 è considerato un valore massimo approssimativo; io ritengo che un valore significativamente inferiore sia ragionevole in ambienti produttivi, specialmente per servizi con un carico pesante [1]. Se la latenza è la priorità assoluta, limitate le vCPU per VM e ottimizzate i thread in modo che possano gestire un carico di base inferiore.

Pratiche di web hosting: effetti sui siti web

Siti web su host sovraccarichi reagiscono con tempi di caricamento più lunghi, tempi instabili per il primo byte e scarse vitalità del web. I motori di ricerca declassano le pagine lente, i visitatori rimbalzano più velocemente e le catene di conversione si interrompono in corrispondenza di microdiluvi poco evidenti [2]. Negli ambienti condivisi, molti conoscono il „vicino rumoroso“; sulle VPS con overcommitment, questo fenomeno si verifica in modo più sottile, perché vengono assegnate nominalmente più vCPU. In caso di picchi di traffico, quindi, verifico sempre prima se i valori di ready e steal sono elevati, invece di modificare ciecamente il server web. Se volete ridurre i costi, dovreste considerare i rischi di webhosting vantaggioso e richiedere limiti chiari contro l'overbooking [2].

Overcommitment vs. bare metal

Confronto mostra: Il metallo nudo offre latenze prevedibili e un throughput lineare, mentre la virtualizzazione sovraccarica diventa instabile sotto carico. Per i carichi di lavoro sensibili alla latenza, come database, code, stack di osservabilità e API in tempo reale, la dedizione si ripaga rapidamente. Preferisco i core dedicati o il bare metal non appena il CPU Ready diventa evidente o gli ospiti SMP si bloccano. Se avete bisogno di flessibilità, potete costruire un ponte con istanze di CPU riservate o gruppi di host senza overcommit. Il confronto offre una visione strutturata delle opzioni Hosting Bare Metal, che confronta brevemente punti di forza e compromessi.

Dimensionamento corretto: quante vCPU hanno senso?

Diritti di proprietà inizia con la domanda reale: Misuro la CPU, la coda di esecuzione, il disco e il Net-IO, nonché i modelli di lock-wait su diversi profili giornalieri. Se i valori misurati mostrano un pool di quattro thread di picco, inizialmente assegno da due a quattro vCPU e le aumento solo se Ready e Co-Stop rimangono poco visibili. La regola empirica „massimo 10 vCPU per core fisico“ è un limite, non un valore target; per la produzione pianifico in modo più conservativo [1]. Le grandi macchine virtuali con molte vCPU sono attraenti, ma aumentano lo sforzo di coordinamento e le fluttuazioni di latenza. Io scalerei orizzontalmente le macchine virtuali piccole e pulite, in modo da mantenere le code brevi ed efficienti.

Monitoraggio e avvisi: cosa ho impostato

Monitoraggio rende visibile l'overcommitment prima che gli utenti se ne rendano conto, per questo ho fissato dei limiti chiari. La CPU Ready nella media di 1 minuto dovrebbe idealmente rimanere al di sotto di 5% per vCPU, il Co-Stop dovrebbe tendere costantemente a zero e lo Steal Time dovrebbe essere percepibile solo per un breve periodo [3]. Se questi valori vengono superati, procedo a scalare orizzontalmente, a parcheggiare i lavori in background lontano dalle macchine virtuali produttive o a spostare i guest su host con aria compressa. Separo gli avvisi in base alla gravità: Allarme immediato per gli aumenti bruschi, ticket per i picchi moderati ricorrenti. In questo modo, prevengo l'affaticamento degli avvisi e intervengo in modo mirato quando la latenza diventa davvero critica per l'azienda.

Selezione del fornitore: Cosa cerco

Selezione di un fornitore di VPS determina la consistenza sotto carico, quindi esamino criticamente le offerte per verificare che non ci sia un overbooking. Informazioni trasparenti sui rapporti vCPU-to-core, promesse chiare sui core dedicati e benchmark coerenti sono obbligatori. In un confronto del 2025, le offerte con storage NVMe, CPU di moderna generazione e nessun overbooking della CPU hanno ottenuto i risultati migliori, con tempi di attività stabili e latenza costante [6]. Il prezzo da solo spesso porta a un overselling nascosto, che diventa più costoso delle risorse oneste negli scenari produttivi. La tabella seguente mostra i parametri fondamentali che ho giustapposto per evitare colli di bottiglia.

Fornitore	vCPU	RAM	Memoria	Tempo di attività	Prezzo/mese	Vincitore del test
webhoster.de	4-32	8-128 GB	NVMe	99,99%	da 1 €	Sì
Hetzner	2-16	4-64 GB	SSD	99,9%	da 3 €	No
Contabo	4-24	8-96 GB	SSD	99,8%	da 5 €	No

Pianificazione della capacità: non appena sono imminenti i picchi di carico

Pianificazione Inizio con i profili dei carichi di lavoro: Tempi di picco, durata dei burst, parallelismo e budget di latenza. Quando il carico di base aumenta, lo aumento prima verticalmente finché il tempo di risposta rimane stabile; se la curva si inclina, divido i servizi su diverse macchine virtuali più piccole. Separo costantemente i lavori in background dal front-end, in modo che i processi di ordine o di checkout non entrino in competizione con i report. L'autoscaling aiuta, ma senza limiti massimi e metriche chiare, produce costose disconnessioni. Una logica graduale funziona meglio: definire le soglie, testare le misure, misurare i risultati e quindi perfezionare le soglie.

Che cos'è veramente una vCPU: effetti SMT e frequenza

vCPU di solito si intende un thread hardware (SMT/hyper-threading), non necessariamente un core fisico completo. Due vCPU possono trovarsi su un core e condividere decodificatori, cache e unità di esecuzione. In condizioni di puro carico di interi o di memoria, l'SMT apporta notevoli vantaggi, ma con pipeline sature, i thread competono direttamente per le risorse. Questo spiega perché gli host con „molte vCPU“ non scalano linearmente sotto carico: Sebbene lo scheduler possa distribuire gli slot, non può creare più unità di calcolo fisiche. Anche le politiche di potenza e di turbo hanno un effetto. Se molti thread vengono eseguiti in parallelo, le frequenze del turbo diminuiscono e le prestazioni del singolo thread si riducono. Per le classi di latenza, considero quindi core dedicati, SMT-Off o pinning della CPU, in modo che i thread ricevano finestre di prestazioni prevedibili.

Consapevolezza NUMA: la localizzazione della memoria decide

NUMA separa i moderni host multi-socket in nodi con una propria connessione di memoria. Le VM SMP di grandi dimensioni che si estendono su più nodi NUMA pagano con una maggiore latenza della memoria, accessi remoti e coordinamento aggiuntivo. Organizzo l'allocazione di vCPU e RAM in modo che una VM si adatti preferibilmente a un nodo. In termini pratici, ciò significa un numero inferiore di vCPU per VM, ma una scalabilità orizzontale. Nel guest, evito pool di thread sovradimensionati e sincronizzati a livello globale e mi affido allo sharding per istanza. Chi virtualizza i database trae un doppio vantaggio: una migliore velocità di accesso alla cache e un minore traffico tra i nodi. L'errata collocazione di NUMA spesso si maschera da „problemi di CPU“, ma diventa visibile nell'aumento della latenza della memoria e dei read miss, mentre il CPU Ready ha solo un effetto moderato.

Modelli a scoppio e a credito: limiti nascosti

Istanze di scoppio con crediti di CPU forniscono buoni valori in modalità idle, ma si strozzano quando non ci sono crediti, anche se il CPU Ready rimane poco evidente. Questo è un problema per gli operatori, perché i picchi di latenza si verificano „dal nulla“. Pertanto, verifico se una tariffa utilizza crediti o regole di „fair share“ e se sono garantite le prestazioni minime. I carichi di lavoro con picchi periodici (cron, ETL, batch di fatture) consumano rapidamente i crediti e poi subiscono una brusca frenata. La soluzione: passare a core riservati o disaccoppiare i burst, ad esempio utilizzando un profilo batch separato con una propria finestra temporale, in modo che le API produttive non incorrano nel throttle. L'overcommitment e il credit throttle sono la combinazione più sfavorevole per ottenere tempi di risposta prevedibili.

Contenitori sul VPS: evitare il doppio scheduling

Orchestrazione dei container in una macchina virtuale già sovraccarica porta facilmente a un „doppio overcommit“. Lo scheduler dell'host dà la priorità alle macchine virtuali, quello del guest ai container, entrambi senza conoscere la reale disponibilità dei core. Per questo motivo ho impostato quote di CPU chiare e ho usato cpuset, per vincolare i container critici a vCPU specifiche. Allo stesso tempo, mantengo la somma dei thread dei container al di sotto del budget realisticamente disponibile della macchina virtuale, non al di sotto del valore nominale delle vCPU. Definisco quote inferiori per i container di build o batch per dare priorità ai servizi front-end. Importante: irqbalance e lo stack di rete non devono sovraccaricare le vCPU critiche con un'ondata di interrupt; in caso di dubbio, isolo una o due vCPU per gli interrupt di rete e di storage per smorzare i picchi di latenza.

Pratica di misurazione: come leggere i numeri giusti

Nell'hypervisor Controllo la CPU Ready (totale e per vCPU), il co-stop e la lunghezza della coda di esecuzione per host. Su KVM, metto in relazione le domstats delle VM con il carico dell'host e il carico degli IRQ. Nell'ospite Osservo %steal, %iowait, coda di esecuzione (r) e cambio di contesto. Uno schema ricorrente è: coda di esecuzione elevata + %steal in aumento + latenza fluttuante = overcommitment. Se %steal rimane basso, ma le misses L3 e le syscalls aumentano, tendo a indicare problemi di ritenzione dei blocchi o NUMA. Conto anche i thread di richiesta attivi e li confronto con i conteggi delle vCPU: se i pool web o worker superano permanentemente il budget di core, creo io stesso delle code. È meglio limitare e rifiutare le code in arrivo invece di elaborarle con un ritardo: questo migliora la percezione degli utenti e stabilizza i sistemi.

Leve di regolazione concrete nell'ospite e nell'host

Profitti rapidi Per ottenere questo risultato, mi avvalgo di alcuni passaggi precisi: Nel BIOS, imposto i profili di prestazione, disattivo gli stati C profondi e mantengo coerente la scalatura della frequenza. Sull'host, imposto il governor della CPU su „performance“ e riduco il rumore dei servizi in background. Nella macchina virtuale, abbasso le vCPU al valore realmente necessario, blocco i processi critici (ad esempio i thread di IO del database) a vCPU fisse e limito i pool di thread delle applicazioni. Quanto segue si applica ai server web e ai runtime: processi_lavoratori (Nginx), pm.max_children (PHP-FPM) o i pool di esecutori JVM non dovrebbero essere più grandi del budget totale disponibile per i core meno l'overhead del sistema. Pagine grandi e fonti di timer coerenti riducono l'overhead di schedulazione; allo stesso tempo, evito un overcommit aggressivo della RAM per evitare che ulteriori latenze di swap entrino nella pipeline.

Progettazione dell'applicazione: contropressione anziché sovraffollamento

Retropressione è la risposta pulita alla scarsità di core. Invece di bufferizzare le richieste in enormi code, limito le richieste elaborate in parallelo ai core più la riserva. I servizi segnalano „occupato“ nei picchi di utilizzo o forniscono risposte degradate ma veloci (ad esempio, cache più corte, meno dettagli). I database hanno timeout di blocco più brevi e transazioni più snelle; le query di ricerca e di analisi vengono eseguite con un ritardo. Nei paesaggi di microservizi, freno ai margini, non in profondità: i gateway API e i limiti di ingresso impediscono alle dipendenze interne di collassare. Il risultato sono code ordinate con code corte: esattamente ciò che salva l'esperienza dell'utente in caso di overcommitment.

Migrazione in tempo reale e carico in background: ostacoli nascosti

Migrazione vMotion/Live o finestre di manutenzione dell'host causano un aumento delle latenze a breve termine, anche se l'overcommitment è moderato. Mentre la memoria viene copiata e gli stati della CPU vengono sincronizzati, le fette di tempo e i percorsi IO vengono spostati. Se l'evento coincide con finestre di batch, i ritardi si accumulano. Pianifico le finestre di migrazione al di fuori degli orari di punta e parcheggio i lavori in esecuzione in parallelo. Inoltre, separo rigorosamente backup/antivirus/indicizzazione dai percorsi di latenza, idealmente sulle mie stesse macchine virtuali a bassa priorità. In questo modo, evito che i processi di manutenzione „ben intenzionati“ distorcano le misurazioni delle prestazioni o colpiscano i flussi degli utenti.

Lista di controllo: Una diagnosi chiara in 15 minuti

• Selezionare il periodo di tempo, riprodurre il carico (test di carico o finestra di picco).
• Hypervisor: Verifica della CPU pronta per vCPU, Co-Stop, Host Run Queue.
• Guest: %steal, %iowait, coda di esecuzione, commutazione di contesto, misurazione del carico IRQ.
• Sincronizza i pool di thread e di worker dell'applicazione con il numero di vCPU.
• Identificare e spostare i lavori in background e le esecuzioni cron.
• Test: dimezzare o bloccare il numero di vCPU, misurare nuovamente Ready/Steal.
• Quando i valori scendono e la latenza si attenua: Dividere orizzontalmente, fissare i limiti.
• Se non ci sono miglioramenti: cambiare host/piano, controllare i core dedicati.

10 idee sbagliate tipiche che costano le prestazioni

Errori Lo vedo regolarmente: un maggior numero di vCPU non significa automaticamente una maggiore velocità se l'host funziona già a una velocità di clock bassa. Un valore di CPU elevato nella VM non richiede l'utilizzo completo dei core finché Ready è alto e Steal è in aumento. Le macchine virtuali SMP di grandi dimensioni non offrono necessariamente un parallelismo migliore se la sincronizzazione e i blocchi dominano. Le funzioni di prioritizzazione dell'hypervisor non eliminano i limiti fisici, ma spostano solo i ritardi. E la messa a punto del database o di PHP nasconde solo brevemente i colli di bottiglia se lo scheduler rimane il vero collo di bottiglia.

Fasi concrete: dai sintomi alla causa

Procedura Inizio in modo riproducibile: prima definisco lo scenario di carico, poi registro i tempi di attesa di CPU Ready, Co-Stop, Steal e IO nella stessa finestra temporale. Se le metriche mostrano le tipiche firme di overcommit, riduco il numero di vCPU per VM, distribuisco i carichi di lavoro SMP e sposto i processi in background. Se i valori rimangono elevati, sposto la VM su un host con un rapporto basso o con core riservati. Se la latenza cambia solo in seguito, salvo il nuovo profilo come linea di base e ancoro gli allarmi a valori percentuali e di millisecondi. In questo modo, non risolvo i sintomi, ma affronto la causa nella pianificazione.

Riassumendo brevemente

SintesiL'overcommitment della CPU sembra efficiente, ma sotto carico crea code che rallentano il server virtuale. Metriche come CPU Ready Time, Co-Stop e Steal Time indicano chiaramente il problema e forniscono soglie oggettive. Red Hat raccomanda rapporti conservativi e macchine virtuali più piccole con meno vCPU, mentre i dati pratici degli ambienti VMware dimostrano l'impatto sul throughput e sui tempi di risposta [1][3]. Per i siti web e le API, se la latenza oscilla, c'è il rischio di perdite di posizioni, rimbalzi e processi a rischio di errore [2]. Per questo motivo, per mantenere affidabili le prestazioni delle VPS, mi affido a un sistema di diritti, a un monitoraggio pulito, a soglie chiare e, se necessario, a core dedicati o a metallo nudo.