CPU Steal Time Explained (and When It Justifies Dedicated Hardware)

Steal time is geen algemene “mijn server is traag”-meter. Het is geen disk latency. Het is geen netwerk latency. Het is ook geen oordeel over je code.

Een veelgemaakte fout is steal time verwarren met I/O wait.

In mpstat betekent %iowait:

• CPU idle tijd terwijl het systeem wacht op disk I/O.

 

In mpstat betekent %steal:

• De vCPU wacht onvrijwillig omdat de hypervisor elders bezig is.

 

Haal je die door elkaar, dan ga je de verkeerde oplossing zoeken.

Optie 1: top (snelste check)

Run:
top

Kijk naar de CPU-samenvatting. Voelt buildtijd, request-afhandeling of queueing traag aan en zie je st tegelijk oplopen, dan heb je een signaal.
Let op: top vermeldt zelf dat het st-veld niet altijd wordt getoond, afhankelijk van kernelversie. Ontbreekt het, gebruik mpstat of vmstat.

Optie 2: mpstat (beste voor sampling)

Als sysstat is geïnstalleerd:
mpstat -P ALL 1 60

Dit geeft per CPU elke seconde samples, inclusief %steal en %iowait.

Kortere meting:
mpstat -P ALL 1 10

Optie 3: vmstat (snel overzicht)

Run:
vmstat 1 10

In vmstat staat onder CPU:

• st: time stolen from a virtual machine.

Optie 4: broncheck via /proc/stat
Wil je tool-interpretatie uitsluiten, kijk dan in /proc/stat.

De cpu-regel bevat meerdere counters, waaronder:

• steal: stolen time while running in a virtualized environment.

 

Veel tools lezen deze data direct uit.

Steal time wordt pas waardevol als je het correleert met symptomen.

Patroon 1: latencypieken vallen samen met steal-pieken
Wat je ziet

• p95 of p99 latency stijgt seconden tot minuten
• queue time loopt op
• requests slagen meestal, maar zijn te laat

 

Wat je doet:

• capture mpstat -P ALL 1 60 tijdens de trage periode
• vergelijk timestamps met je latencygrafiek

 

Stijgen latency en %steal samen, dan zit de vertraging waarschijnlijk vóór je code.

Patroon 2: load average stijgt, maar je app “krijgt geen CPU”
Dit is waar teams vastlopen:

• load average stijgt
• latency stijgt
• user CPU stijgt niet zoals verwacht
• steal time stijgt

 

Taken zijn runnable, maar je VM wacht op echte CPU-tijd.

Controleer de run queue:
sar -q 1 10

sar -q toont runq-sz, de lengte van de run queue. Dat is een nuttig signaal voor schedulerdruk.

Patroon 3: aanhoudende steal onder normale load
Pieken gebeuren. Korte host-events ook.

Wat prestaties raakt, is herhaalbare steal time onder normale workload, vooral als dit samenvalt met tail latency.
De richtlijn van Red Hat is helder: grote hoeveelheden steal time duiden op CPU-contest en verminderen guest-prestaties.

Deze sectie is er met een reden. Sla je dit over, dan wordt je standaardreactie “dedicated totdat het tegendeel bewezen is”. Dat is geen engineering.
Gebruik deze eliminatiechecklist.

1) Is %steal bijna nul tijdens de slowdown? Check CPU-throttlingmodellen

Bijvoorbeeld burstable CPU credit-modellen. Als credits op zijn, valt de instance terug naar baseline CPU-gedrag. Dat voelt als “willekeurige traagheid” met lage of nul steal time.

2) Draai je containers? Check eerst cgroup CPU-throttling

In Kubernetes worden CPU-limieten afgedwongen via throttling. Een container kan traag zijn door zijn CPU-limit, zelfs als de VM zelf nauwelijks steal time toont.

3) Is %iowait hoog? Dan ben je storage-bound

Hoge %iowait met lage %steal wijst op:

• disk
• filesystem
• database I/O
• storage contention

 

Steal time is geen storage-metric. Behandel het zo en je verspilt dagen.

4) Denk aan NUMA en pinning bij CPU-placementproblemen

NUMA-placement kan echte performanceklappen veroorzaken. Gebruik je vCPU-pinning, dan moet NUMA-tuning mee. Anders creëer je onnodige misses en onvoorspelbaar gedrag.
Dit speelt vooral als je de host beheert, maar kan ook relevant zijn in managed omgevingen.

5) Vallen slowdowns samen met onderhoud? Denk aan live migratie

Live migratie bestaat en veroorzaakt korte jitter. Tijdens live migratie blijft de guest draaien terwijl memory wordt verplaatst. Niet aannemen. Correlatie checken.

6) Verandert CPU-frequentie? Dan verandert performance

CPU frequency scaling is echt. Hogere frequentie betekent meestal meer instructies per tijdseenheid, met hoger energieverbruik. Governors en scaling-algoritmes passen gedrag aan op load.
Komt vaker voor op eigen hardware, maar is meetbaar en hoort in je mentale model.

Dit is het actiegerichte deel.

Stap 1: bewijs de correlatie

Tijdens een slowdown:

• mpstat voor %steal en %iowait
• sar -q voor run queue pressure
• p95 en p99 latency uit APM of logs
• timestamps van deploys en background jobs

Commando’s

mpstat -P ALL 1 60
sar -q 1 60
vmstat 1 60

Matchen latencypieken en steal-pieken, dan heb je bewijs van CPU-schedulingcontendie upstream. Piekt %iowait in plaats daarvan, stop dan met praten over dedicated. Je hebt een I/O-probleem.

Stap 2: beslis of dit binnen VPS-land oplosbaar is

Vraag je provider:

• Kunnen jullie me verplaatsen naar een andere host?
• Bieden jullie dedicated vCPU of lagere oversubscription?
• Kunnen jullie bevestigen of CPU overcommit wordt gebruikt op dit hosttype?

 

Kunnen ze dit niet beantwoorden, dan is dat ook een antwoord.

Stap 3: gebruik een pragmatische escalatieregel

Er is geen universele drempel. Maar je hoeft niet perfect te meten om te handelen.
Een veel geciteerde vuistregel:

• Is steal time hoger dan 10 procent gedurende 20 minuten, dan draait de VM waarschijnlijk trager dan nodig.

 

Zie dit als escalatietrigger, niet als natuurwet. Voor latency-gevoelige systemen ben je vaak eerder klaar. Niet omdat CPU “vol” zit, maar omdat tail latency oploopt.

Stap 4: weet wat er verandert bij dedicated

Dedicated hardware haalt één grote variabele weg:

• gedeelde CPU-scheduling met andere tenants.

 

Was steal time het probleem, dan zou deze onder vergelijkbare load vrijwel naar nul moeten gaan.
Wees precies. Steal time is een virtuele CPU-metric. Installeer je zelf een hypervisor op dedicated hardware en ga je overcommitten, dan kun je steal time opnieuw creëren.
Dedicated verwijdert de noisy neighbor. Het verwijdert geen slechte capaciteitsplanning.

Meet succes niet op gevoel. Meet het zoals een engineeringteam dat doet.

Als steal time de oorzaak was, dan zie je:

• %steal blijft dicht bij nul onder dezelfde load
• p95 en p99 latency stabiliseren
• buildtijden worden voorspelbaar
• incidenten bevatten niet langer “niet reproduceerbaar” of “ging vanzelf weg”

 

Blijft steal laag maar blijft latency instabiel, dan heb je bewijs dat de bottleneck elders zit. Vaak I/O, throttling of applicatiecontentie.
Dat is nog steeds winst. Het vernauwt het probleem.