CPU-overcommitment: hoe het virtuele servers vertraagt

CPU overcommitment vertraagt virtuele servers omdat de hypervisor meer vCPU's toewijst dan er fysieke cores zijn, wat resulteert in wachttijden. Ik laat de oorzaken zien, echte meetwaarden zoals CPU Ready Time en specifieke aanpassingen die ik gebruik om de VPS prestaties stabiel te houden.

Centrale punten

Voordat ik dieper inga, zal ik de belangrijkste aspecten categoriseren en typische misverstanden uit de doeken doen. Veel operators verwarren een hoge bezettingsgraad met efficiëntie, hoewel wachtrijen de reactietijden bepalen. Details van de planner bepalen of applicaties soepel lopen of vastlopen. Ik vat de kernonderwerpen samen waarop ik in de volgende hoofdstukken zal voortbouwen. De lijst dient als een compacte referentie voor snelle beslissingen.

• planner en time slicing bepalen hoe de vCPU's worden toegewezen.
• CPU gereed geeft wachttijden weer en waarschuwt vroegtijdig voor knelpunten.
• SMP gasten (meerdere vCPU's) verhogen de overhead en latency.
• Rechten en monitoring houden piekbelastingen beheersbaar.
• Aanbiederselectie zonder overboeking zorgt voor constante prestaties.

Wat betekent CPU overcommitment technisch gezien?

Overcommit Dit betekent dat ik meer virtuele cores toewijs dan de host fysiek heeft en vertrouw op de hypervisor scheduler. KVM of VMware wijzen rekentijd toe via time slicing, wat onopvallend is bij lage belasting en hoge dichtheid mogelijk lijkt te maken. Bij parallelle belasting nemen de wachttijden echter toe omdat meerdere vCPU's tegelijkertijd rekentijd nodig hebben en de scheduler ze achter elkaar moet inplannen. Red Hat waarschuwt dat met name SMP VM's met veel vCPU's veel prestaties verliezen zodra de som van de vCPU's het aantal fysieke cores aanzienlijk overschrijdt [1]. VMware-experts kwantificeren dit via CPU Ready Time: 1000 ms wachttijd per vCPU komt overeen met ongeveer 5% prestatieverlies, cumulatief per core [3].

Waarom virtuele servers langzamer worden

Wachtrijen zijn de belangrijkste reden waarom virtuele servers langzamer worden als ze overboekt zijn, ook al lijkt het CPU-gebruik hoog. Een vCPU mag alleen draaien als er een fysieke core vrij is; tot die tijd neemt CPU Ready toe en wacht de applicatie. Met meerdere VM's met parallelle pieken wordt het effect verergerd omdat ze allemaal „klaar om te draaien“ zijn en de planner alleen in tijdschijven kan werken. Vooral latency-kritische werklasten zoals databases, API's of shop backends reageren gevoelig, omdat elke extra contextverandering en elke vertraging kettingeffecten veroorzaakt. Ik observeer dan timeouts, onregelmatige responstijden en een toenemende variantie die gebruikers merkbaar irriteert.

Gemeten variabelen: CPU Ready, Steal & Co.

Indicatoren zoals CPU Ready, Co-Stop en Steal Time laten me in een vroeg stadium zien of overcommitment invloed heeft op mijn VM. CPU Ready in hypervisor-metriek moet gemiddeld ruim onder 5% blijven; als de waarde stijgt tot dubbele cijfers, daalt de doorvoer merkbaar [3]. Co-Stop geeft aan dat SMP VM's niet tegelijkertijd gepland kunnen worden, wat multi-threading vertraagt. In Linux gasten lees ik Steal Time af, wat laat zien hoeveel tijd de host van mijn VM afneemt; ik heb de achtergrond en afstemming hier op een toegankelijke manier uitgelegd: CPU-stealtijd. Als je deze drie signalen combineert, kun je tijdig knelpunten herkennen en voorkomen dat latentieproblemen doorwerken in de applicatie.

Een echt voorbeeld: Wanneer 5:1 de limiet doorbreekt

Praktijk verslaat de theorie zodra echte werklasten zich mengen: Een host met 4 fysieke cores en 5 VM's met elk 4 vCPU's lijkt onproblematisch in rust, maar vertoont enorme wachttijden onder belasting. Als een VM begint met beeldverwerking of back-ups, geeft de planner voorrang, maar de resterende VM's accumuleren CPU-ready waarden van meer dan 2000 ms, wat een prestatieverlies betekent van ongeveer 10% per core [3]. In een gedocumenteerde SQL-servertest daalde de doorvoer van 25.200 transacties per minuut naar minder dan de helft [3] toen de achtergrondbewerking werd geactiveerd. I/O vertraagt ook indirect omdat vCPU's worden gepreempt tijdens toegang tot blokapparaten en de pijplijnen vastlopen. Ik ervaar dan een mix van hoge pieken, lange staarten en onverwachte jitter in responstijden.

Speciale risico's voor SMP-gasten

SMP-VM's VM's met veel vCPU's hebben gecoördineerde slots nodig op meerdere fysieke cores, waardoor de planningsinspanning en wachttijden toenemen. Hoe meer vCPU's een enkele VM heeft, hoe vaker deze moet wachten tot alle benodigde tijdplakken bij elkaar komen. Red Hat adviseert daarom om de voorkeur te geven aan meerdere kleinere VM's met weinig vCPU's in plaats van individuele „wide-gauge“ gasten te draaien [1]. Een overcommit ratio van 10:1 wordt beschouwd als een ruwe maximumwaarde; ik beschouw aanzienlijk minder als verstandig in productieve omgevingen, vooral voor diensten met een zware belasting [1]. Als latentie de hoogste prioriteit heeft, beperk dan de vCPU's per VM en optimaliseer threads zodat ze het met minder core-basisbelasting kunnen doen.

Webhostingpraktijk: effecten op websites

Websites op overboekte hosts reageren met langere laadtijden, onstabiele tijd tot de eerste byte en slechte kernwaarden van het web. Zoekmachines degraderen trage pagina's, bezoekers haken sneller af en conversieketens breken op onopvallende microvertragingen [2]. In gedeelde omgevingen zijn veel mensen bekend met de „luidruchtige buurman“; op VPS'en met overcommitment gebeurt dit subtieler omdat er nominaal meer vCPU's worden toegewezen. Bij pieken in het verkeer verifieer ik daarom altijd eerst of de ready en steal waarden hoog zijn in plaats van blindelings de webserver te tweaken. Als je kosten wilt besparen, moet je rekening houden met de risico's van voordelige webhosting en eisen duidelijke grenzen tegen overboeking [2].

Overcommitment vs. kaal metaal

Vergelijking laat zien: Bare metal levert voorspelbare latenties en lineaire doorvoer, terwijl overboekte virtualisatie instabiel wordt onder belasting. Voor latency-gevoelige werklasten zoals databases, wachtrijen, observability stacks en realtime API's betaalt toewijding zich snel terug. Ik geef de voorkeur aan dedicated cores of bare metal zodra CPU Ready merkbaar wordt of SMP-gasten vastlopen. Als je flexibiliteit nodig hebt, kun je een bridge bouwen met gereserveerde CPU instances of hostgroepen zonder overcommit. De vergelijking biedt een gestructureerd overzicht van de opties Bare Metal Hosting, waarin de sterke punten en compromissen kort worden vergeleken.

Juiste dimensionering: Hoeveel vCPU's zijn zinvol?

Rechten begint met de echte vraag: Ik meet CPU, runwachtrij, schijf en Net-IO en lock-wachtpatronen over verschillende dagprofielen. Als de gemeten waarden een piek threadpool van vier laten zien, wijs ik in eerste instantie twee tot vier vCPU's toe en verhoog deze alleen als Ready en Co-Stop onopvallend blijven. De vuistregel „maximaal 10 vCPU's per fysieke core“ is een limiet, geen doelwaarde; ik plan conservatiever voor productie [1]. Grote VM's met veel vCPU's zien er aantrekkelijk uit, maar vergroten de coördinatie-inspanning en latency-schommelingen. Ik schaal kleine, schone VM's horizontaal en houd zo wachtrijen kort en efficiënt.

Bewaking en waarschuwingen: wat ik instel

Controle maakt overcommitment zichtbaar voordat gebruikers het doorhebben, daarom heb ik duidelijke limieten ingesteld. CPU Ready in het gemiddelde van 1 minuut zou idealiter onder 5% per vCPU moeten blijven, Co-Stop zou permanent naar nul moeten neigen en Steal Time zou slechts korte tijd merkbaar moeten zijn [3]. Als dit wordt overschreden, schaal ik horizontaal, parkeer achtergrondtaken uit de buurt van productieve VM's of verplaats gasten naar hosts met lucht. Ik scheid waarschuwingen op basis van ernst: Directe waarschuwing voor scherpe stijgingen, ticket voor terugkerende gematigde pieken. Op deze manier voorkom ik waarschuwingsmoeheid en grijp ik specifiek in wanneer latency echt bedrijfskritisch wordt.

Aanbiederselectie: Waar ik op let

Selectie van een VPS-provider bepaalt consistentie onder belasting, dus ik kijk kritisch naar aanbiedingen voor overboeking. Transparante informatie over vCPU-to-core ratio's, duidelijke beloftes over dedicated cores en consistente benchmarks zijn verplicht. In een vergelijking uit 2025 presteerden aanbiedingen met NVMe-opslag, moderne CPU-generatie en geen CPU-overboeking het beste, met stabiele uptime en consistente latency [6]. Prijs alleen leidt vaak tot verborgen overselling, die duurder wordt dan eerlijke bronnen in productieve scenario's. De volgende tabel toont kernparameters die ik naast elkaar zet om knelpunten te vermijden.

Aanbieder	vCPU's	RAM	Geheugen	Uptime	Prijs/maand	Testwinnaar
webhoster.de	4-32	8-128 GB	NVMe	99,99%	vanaf 1 €	Ja
Hetzner	2-16	4-64 GB	SSD	99,9%	vanaf 3 €	Geen
Contabo	4-24	8-96 GB	SSD	99,8%	vanaf 5 €	Geen

Capaciteitsplanning: zodra belastingspieken dreigen

Planning Ik begin met werklastprofielen: Piektijden, burst-duur, parallellisme en latency-budgetten. Als de basisbelasting toeneemt, verhoog ik eerst verticaal zolang de klaar-tijd stabiel blijft; als de curve kantelt, verdeel ik services over meerdere kleinere VM's. Ik scheid achtergrondtaken consequent van de frontend zodat bestelprocessen of afrekenen niet concurreren met rapporten. Automatisch schalen helpt, maar zonder bovengrenzen en duidelijke metriek levert het dure verkeerde verbindingen op. Een stapsgewijze logica werkt beter: drempels definiëren, maatregelen testen, resultaten meten en dan drempels bijstellen.

Wat een vCPU echt is: SMT en frequentie-effecten

vCPU betekent meestal een hardware thread (SMT/hyper-threading), niet noodzakelijk een volledige fysieke core. Twee vCPU's kunnen zich op één core bevinden en decoders, caches en uitvoeringseenheden delen. Bij pure integer- of geheugenbelasting biedt SMT merkbare voordelen, maar bij verzadigde pijplijnen concurreren threads direct om bronnen. Dit verklaart waarom hosts met „veel vCPU's“ niet lineair schalen onder belasting: Hoewel de planner slots kan verdelen, kan hij niet meer fysieke rekeneenheden creëren. Vermogen en turbobeleid hebben ook een effect. Als veel threads parallel draaien, dalen de turbofrequenties en nemen de prestaties van enkele threads af. Voor latency klassen overweeg ik daarom dedicated cores, SMT-Off of CPU pinning om threads voorspelbare prestatievensters te geven.

NUMA-bewustzijn: geheugenlokaliteit beslist

NUMA verdeelt moderne multi-socket hosts in nodes met hun eigen geheugenverbinding. Grote SMP VM's die zich uitstrekken over meerdere NUMA nodes betalen met hogere geheugenlatentie, toegang op afstand en extra coördinatie. Ik organiseer de toewijzing van vCPU en RAM zodat een VM bij voorkeur op een node past. Praktisch gezien betekent dit minder vCPU's per VM, maar horizontale schaalbaarheid. In de gast vermijd ik te grote, globaal gesynchroniseerde threadpools en vertrouw ik op sharding per instantie. Degenen die databases virtualiseren profiteren dubbel: een betere cache hit rate en minder verkeer tussen de knooppunten. NUMA-verplaatsing vermomt zich vaak als „CPU-problemen“, maar het wordt zichtbaar in toenemende geheugenlatentie en leesmissers, terwijl CPU Ready slechts een matig effect heeft.

Barst- en kredietmodellen: verborgen grenzen

Uitbarstingen met CPU-credits leveren goede waarden in idle modus, maar geven gas als er geen credits zijn, hoewel CPU Ready onopvallend blijft. Dit is lastig voor operators omdat latentiepieken „uit het niets“ optreden. Ik controleer daarom of een tarief credits of „fair share“ regels gebruikt en of minimale prestaties gegarandeerd zijn. Workloads met periodieke pieken (cron, ETL, invoice batch) vreten snel credits op en komen dan in een harde rem terecht. De oplossing: schakel over op gereserveerde cores of ontkoppel bursts - bijvoorbeeld door een apart batchprofiel te gebruiken met een eigen tijdvenster zodat productieve API's niet tegen de throttle aanlopen. Overcommitment plus credit throttle is de meest ongunstige combinatie voor voorspelbare responstijden.

Containers op de VPS: voorkom dubbel plannen

Containerorkestratie in een VM die al overboekt is, leidt gemakkelijk tot „dubbele overcommit“. De hostplanner geeft prioriteit aan VM's, de gastplanner geeft prioriteit aan containers - beide zonder kennis van de werkelijke kernbeschikbaarheid. Ik stel daarom duidelijke CPU-quota in en gebruik cpuset, om kritieke containers aan specifieke vCPU's te binden. Tegelijkertijd houd ik de som van container threads onder het realistisch beschikbare budget van de VM, niet onder de nominale vCPU-waarde. Ik definieer lagere aandelen voor build- of batchcontainers om prioriteit te geven aan front-end services. Belangrijk: irqbalans en netwerk-stack mogen geen kritieke vCPU's overspoelen met interrupt floods; bij twijfel isoleer ik één of twee vCPU's voor netwerk- en opslag interrupts om latency pieken te dempen.

Meetoefeningen: de juiste getallen lezen

In de hypervisor Ik controleer CPU Ready (totaal en per vCPU), co-stop en run queue length per host. Op KVM correleer ik domstats van de VM's met hostbelasting en IRQ-belasting. In de gast Ik observeer %steal, %iowait, run queue (r) en contextveranderingen. Een terugkerend patroon is: Hoge run queue + toenemende %steal + fluctuerende latency = overcommitment. Als %steal laag blijft, maar L3 misses en syscalls toenemen, ben ik geneigd om te wijzen op lock retentie of NUMA problemen. Ik tel ook actieve verzoekthreads en vergelijk ze met vCPU-tellingen: als web- of workerpools permanent boven het core-budget zitten, maak ik zelf wachtrijen aan. Het is beter om binnenkomende wachtrijen te beperken en af te wijzen in plaats van ze met vertraging te verwerken - dit verbetert de gebruikersperceptie en stabiliseert systemen.

Concrete afstemhendels in de gast en gastheer

Snelle winst Ik bereik dit met een paar precieze stappen: In het BIOS stel ik prestatieprofielen in, deactiveer ik diepe C-states en houd ik de frequentieschaling consistent. Op de host stel ik de CPU-governor in op „performance“ en verminder ik ruis van achtergronddiensten. In de VM verlaag ik de vCPU's tot de werkelijk vereiste waarde, zet ik kritieke processen (bijvoorbeeld database IO threads) vast op vaste vCPU's en beperk ik de threadpools van applicaties. Het volgende geldt voor webservers en runtimes: werker_processen (Nginx), pm.max_kinderen (PHP-FPM) of JVM executor pools mogen niet groter zijn dan het totale beschikbare core budget min de systeemoverhead. Grote pagina's en consistente timerbronnen verminderen de scheduling overhead; tegelijkertijd vermijd ik agressieve overcommit van RAM om te voorkomen dat er extra swap latenties in de pijplijn komen.

Toepassingsontwerp: Tegendruk in plaats van overbevolking

Tegendruk is het schone antwoord op schaarse cores. In plaats van verzoeken te bufferen in enorme wachtrijen, beperk ik parallel verwerkte verzoeken tot de cores plus reserve. Diensten geven aan dat ze „bezig“ zijn op piekmomenten of leveren verminderde maar snelle antwoorden (bijv. kortere caches, minder details). Databases krijgen kortere lock timeouts en slankere transacties; zoek- en analysequery's draaien met een tijdsvertraging. In microservice landschappen rem ik aan de rand, niet in de diepte: API gateways en ingress limieten voorkomen dat interne afhankelijkheden instorten. Het resultaat zijn ordelijke wachtrijen met korte staarten - precies wat de gebruikerservaring redt onder overcommitment.

Live migratie en achtergrondbelasting: verborgen struikelblokken

vMotion/Live-migratie of host onderhoudsvensters veroorzaken verhoogde latenties op de korte termijn, zelfs als de overcommitment gematigd is. Terwijl geheugen wordt gekopieerd en CPU toestanden worden gesynchroniseerd, worden tijdschijven en IO paden verschoven. Als de gebeurtenis samenvalt met batchvensters, stapelen de vertragingen zich op. Ik plan migratievensters buiten piektijden en parkeer taken die parallel lopen. Ik scheid back-up/antivirus/indexering ook strikt van latentiepaden - idealiter op mijn eigen VM's met lage prioriteit. Op deze manier voorkom ik dat „goedbedoelde“ onderhoudsprocessen prestatiemetingen verstoren of gebruikersstromen raken.

Checklist: Een duidelijke diagnose in 15 minuten

• Selecteer tijdsperiode, reproduceer belasting (belastingstest of piekvenster).
• Hypervisor: Controle CPU Ready per vCPU, Co-Stop, Host Run Queue.
• Gast: %steal, %iowait, run queue, contextswitch, IRQ-belasting meten.
• Synchroniseer de thread- en workerpools van de applicatie met het vCPU-nummer.
• Achtergrondtaken en cron-runs identificeren en verplaatsen.
• Oplossing: Halveer of pin het vCPU-nummer, meet Ready/Steal opnieuw.
• Wanneer waarden dalen en latentie afvlakt: Horizontaal splitsen, grenzen vastleggen.
• Indien geen verbetering: Verander host/plan, controleer specifieke cores.

10 typische misvattingen die prestaties kosten

Fouten Ik zie dit regelmatig: Meer vCPU's betekent niet automatisch meer snelheid als de host al op een lage kloksnelheid draait. Een hoge CPU-waarde in de VM vereist geen volledige corebenutting zolang Ready hoog is en Steal toeneemt. Grote SMP VM's leveren niet noodzakelijk beter parallellisme op als synchronisatie en vergrendelingen domineren. Prioriteringsfuncties van de hypervisor nemen geen fysieke limieten weg; ze stellen alleen vertragingen uit. En database of PHP tuning verhult slechts kortstondig knelpunten als de scheduler de echte bottleneck blijft.

Concrete stappen: van symptomen naar oorzaak

Procedure Ik begin reproduceerbaar: definieer eerst het belastingsscenario, registreer dan CPU Ready, Co-Stop, Steal en IO wachttijden in hetzelfde tijdsvenster. Als de statistieken typische overcommit-handtekeningen laten zien, verlaag ik het aantal vCPU's per VM, verdeel ik SMP-werklasten en verplaats ik achtergrondprocessen. Als de waarden hoog blijven, verplaats ik de VM naar een host met een lage ratio of gereserveerde cores. Als de latency dan pas verandert, sla ik het nieuwe profiel op als basislijn en veranker ik alarmen naar percentage- en millisecondewaarden. Op deze manier los ik geen symptomen op, maar pak ik de oorzaak aan in de planning.

Kort samengevat

SamenvattingCPU overcommitment klinkt efficiënt, maar onder belasting creëert het wachtrijen die de virtuele server vertragen. Metrieken zoals CPU Ready Time, Co-Stop en Steal Time geven het probleem duidelijk aan en bieden objectieve drempelwaarden. Red Hat adviseert conservatieve ratio's en kleinere VM's met weinig vCPU's, terwijl praktijkgegevens uit VMware-omgevingen de impact op doorvoer en responstijden bewijzen [1][3]. Voor websites en API's bestaat het risico van rankingverlies, bounces en foutgevoelige processen als de latentie fluctueert [2]. Ik vertrouw daarom op rightsising, schone monitoring, duidelijke drempels en - indien nodig - dedicated cores of bare metal om de VPS-prestaties betrouwbaar te houden.