Hoe we CPU-stealtime verminderden met wel 83%

We hebben CPU-pinning uitgezet op meer dan 1.000 virtuele machines en de stealtime daardoor met gemiddeld 83% verminderd. VM’s die voor deze aanpassing 11% van hun tijd besteedden aan wachten op CPU-resources hebben nu nog maar een wachttijd van minder dan 0.1%! In dit artikel leggen we je exact uit hoe we dat voor elkaar hebben gekregen.

Wat is CPU-stealtime?

Als een virtuele machine een proces moet verwerken, maar in de wachtrij moet omdat de CPU met een ander proces bezig is, telt de wachttijd als ‘gestolen’. Een hoge stealtime (van 5-10%) betekent dat applicaties langzamer draaien dan verwacht.

Oorspronkelijk leek CPU-pinning een goed idee. Door virtuele CPU’s vast te pinnen aan specifieke fysieke cores, verminder je context switching en verbetert de voorspelbaarheid van de performance.

Maar we begonnen gekke dingen te zien bij een aantal klanten. VPS-instances hadden een hoger dan verwachte stealtime. Met onze goedbedoelde CPU-pinning hadden we een strijd veroorzaakt tussen vCPU’s en I/O threads die dezelfde gepinde cores wilden gebruiken.

De hypothese

Wat nou als we de CPU pins verwijderen?

In plaats van PerformanceVPS-cores te forceren om specifieke hardware threads te gebruiken, laten we de Linux-scheduler doen wat die het beste doet: resources dynamisch toewijzen gebaseerd op systeemtopologie en workload-patronen.

De theorie: dynamische CPU-scheduling zou zwaarder opwegen tegen potentiële context switching overhead.

Het experiment

We ontwierpen een gecontroleerde roll-out op onze infrastructuur:

Dataset: 1.000 domeinen over 4 pods.

Metric: CPU stealtime (hoe lager de stealtime, des te beter de performance).

Methode: Voor/na analyse met tracking op infrastructuurmigraties.

Tijdslijn:

Voor: 20 april – 18 mei 2025
Na: 1 juni – 29 juni 2025

De resultaten

Totaal aantal VPS’en geanalyseerd: 1K+

VPS met verbeterde performance: 98.8%

VPS met verminderde performance: 1.2%

Gemiddelde verbetering: 82.27%

Beste verbetering gemeten: 99.9%

Statistische significantie: p < 1e-19 ✓

De slechtst presterende VPS-instances hadden de grootste verbeteringen. CPU-pinning had de meeste invloed op workloads die toch al worstelden met de druk. Voor en na zijn gemiddelden.

Statistieke validatie

Voor deze resultaten hebben we de volgende analyses gedaan:

Gepaarde t-toets: t = 9.230, p = 1.64e-19
Wilcoxon signed-rank toets: p = 1.07e-157
Effectgrootte (Cohen’s d) 0.414 (klein maar significant)
Statistische significantie: p < 1e-19

De distributie leunde hevig richting verbetering, wat aangaf dat de meeste instances significante winst hebben geboekt.

De technische deepdive

Waarom CPU-pinning resource-conflicten opleverde

Er ontstond wrijving tussen processen over resources door slechte CPU-toewijzing. Als we VPS-cores op specifieke hardware-threads pinden, creëerden we zelf scenarios waarin:

vCPU’s gepind waren op specifieke fysieke cores
I/O-threads ook gepind waren op die specifieke fysieke cores
Ze met elkaar concurreerden om dezelfde CPU-resources
CPU-stealtime omhoog ging omdat VM’s aan het wachten waren op toegang tot hun gepinde cores.

Dit leverde een groot probleem op: omdat onze VPS-instances gemiddeld maar zo’n 10% van hun CPU gebruiken zouden we in theorie genoeg ongebruikte CPU-capaciteit moeten hebben, maar door de slechte toewijzing konden VM’s er niet bijkomen.

Het voordeel van scheduling

Met het verwijderen van de CPU-pinning kon de Linux scheduler automatisch de meest optimale resource-toewijzing toepassen. Nu kon hij:

vCPU-threads dynamisch verdelen over alle beschikbare cores
Resource-conflicten verminderen door processen die botsten uit elkaar te halen
Workloads balanceren gebaseerd op actuele CPU-beschikbaarheid
Optimalisaties waar nodig automatisch toepassen, inclusief NUMA-balancing waar nodig
Zich realtime automatisch aanpassen aan veranderende workload-patronen

De context bij virtualisatie

Onze infrastructuur runt op KVM-gebaseerde volledige virtualisatie. Binnen KVM opereren gast-VM’s in geïsoleerde virtuele hardware-omgevingen. Ze zien alleen wat de hypervisor ze voert (bijvoorbeeld 4 vCPU’s op 1 socket). De gast-VM’s hebben geen idee van de onderliggende fysieke hardware-layout.

Door het verwijderen van CPU-pinning kon de hypervisor nu veel beter:

Dynamisch vCPU-threads schedulen over alle beschikbare fysieke cores
Automatische NUMA-balancering inzetten voor betere memory-toewijzing
Resource-conflicten verminderen door de Linux-scheduler workloads optimaal te laten verdelen

De gast-VM’s merkten niets van deze optimalisaties op host-level.

Wat we hebben geleerd

Blijf sceptisch over je eigen aannames

CPU-pinning wordt vaak aangeraden voor gevirtualiseerde omgevingen, maar context is belangrijk. Wat wel werkt voor bare-metal, werkt misschien niet voor multi-tenant-systemen.

Meet alles

Zonder de alomvattende metrics die verzameld konden worden via Prometheus, had het ons veel langer gekost om deze optimalisatiestappen te nemen. De data vertelde ons wat onze intuïtie ons niet kon vertellen.

Moderne schedulers zijn flink doorontwikkeld

De Linux CFS-scheduler heeft letterlijk jaren van ontwikkeling doorgemaakt. Soms is de beste manier om performance te verbeteren, simpelweg hem gewoon zijn ding te laten doen.

Conclusie

Deze optimalisatie staat voor veel meer dan alleen een performance-verbetering. Het is de validatie van een performance engineering principe: limiteringen zorgen vaak juist voor de problemen die ze proberen op te lossen.

De verbetering van 83% kwam niet door complexiteit toe te voegen, maar juist door die weg te halen. Soms is de beste oplossing juist de meest simpele.

Wat dit betekent voor PerformanceVPS-klanten

Hoewel deze optimalisatie wel aanpassingen aan de infrastructuur met zich meebrengt, behouden PerformanceVPS-klanten de garantie dat ze dezelfde resources krijgen die ze altijd al hadden. Alleen nu met flink verbeterde performance.

De resource-garantie blijft ongewijzigd

Geen CPU-overprovisioning: we behouden onze stricte 1:1 vCPU tot fysieke core-ratio
Dezelfde dedicated-toewijzing: De vCPU’s in jouw contract behouden hun toegang tot hun volledige rekenkracht
Consistente resource-beschikbaarheid: Geen veranderingen in core/RAM-ratio’s of add-on-configuraties

De verbeteringen die je wel zult voelen

Dramatisch verbeterde wachttijden: applicaties die hiervoor 11% CPU-wachttijd hadden, hebben nu minder dan 0.1% wachttijd
Verbeterde consistentie in performance: in het bijzonder nuttig voor workloads met gevarieerde vCPU-vraag
Beter gebruik van resources: De scheduler optimaliseert nu dynamisch, gebaseerd op daadwerkelijke gebruikspatronen
Verbeterde response: het meest voelbaar tijdens piekbelastingsmomenten

De technische realiteit

In plaats van jouw vCPU’s vast te hangen aan suboptimale fysieke cores, hebben ze nu toegang tot de best-presterende cores die op dat moment beschikbaar zijn. Je krijgt dezelfde gegarandeerde rekenkracht waar je voor betaalt, maar dan met veel betere performance-optimalisatie, uitgevoerd op hypervisor-niveau.

Praktisch gezien zullen jouw applicaties nu sneller en consistenter draaien, met minder variatie in performance, maar wel met dezelfde resource-garanties waar PerformanceVPS op gebouwd is.

Methodologie

Dataverzameling: Prometheus-queries meten libvirt_domain_vcpu_**
Statistieke analyse: meerdere normaliteitstesten, gepaarde hypothesetoetsen, effect-grootte berekening
Infrastructuur: 4 pods met verschillende workload types
Validatie: Bootstrap confidence intervals, outlier analyse, correlatiestudies