Wat is CPU steal time op een VPS en hoe meet u dit?

Wat CPU steal time daadwerkelijk meet

CPU steal time is het aandeel van de tijd dat uw virtuele CPU klaar was om te draaien, zonder op iets te hoeven wachten, terwijl de hypervisor de fysieke core aan een andere gast toewees. Het werk stond in de wachtrij. De core was ergens anders bezig. Linux telt die cycli afzonderlijk en rapporteert ze als st. Hiermee kunt u het onderscheid maken tussen "mijn server is bezet" en "mijn server wacht op zijn beurt".

Dat verschil is de enige reden waarom deze teller bestaat. Tijd die uw eigen processen op de CPU doorbrengen, wordt gerapporteerd als us (user) of sy (system). Tijd die een taak geblokkeerd door opslag doorbrengt, wordt gerapporteerd als wa (I/O wait). Een vCPU (virtuele CPU) die uitvoerbaar is, in de run queue staat, geen openstaande I/O heeft en toch niet wordt uitgevoerd, wordt gerapporteerd als st. Niets binnen uw server kan die status verhelpen, omdat de beslissing over de planning één laag onder u wordt genomen, op de host.

Dit vloeit direct voort uit hoe een VPS één fysieke machine deelt tussen vele gasten. De gebruikelijke oorzaak is een buurman: een andere gast op hetzelfde knooppunt draait zwaar, waardoor de host de cores tussen u verdeelt. Er is een tweede oorzaak die vaak over het hoofd wordt gezien. Veel providers beperken een gedeelde vCPU tot een fractie van een fysieke core, en op verschillende hypervisors wordt die afgedwongen limiet in de gast als steal geregistreerd. Een hoge st-waarde vertelt u dus dat de core niet aan u werd toegewezen. Het vertelt u niet altijd wie hem heeft ingenomen.

Waar het steal-getal vandaan komt

Uw kernel kan steal niet zelf meten, omdat deze de host niet kan zien. De hypervisor geeft dit door. Op KVM schrijft de host een per-vCPU-teller naar een pagina die wordt gedeeld met de guest, en de guest telt dit op wanneer de kernel is gebouwd met CONFIG_PARAVIRT_TIME_ACCOUNTING, wat bij elke distributie-kernel het geval is. Xen rapporteert hetzelfde via zijn runstate-gebied. Het totaal bereikt de userspace op precies één plek:

head -1 /proc/stat

Die cpu-regel bevat tien tellers, in USER_HZ-ticks sinds het opstarten, in deze volgorde: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. Steal is de achtste waarde na het label. Elke tool hieronder, vmstat, top, mpstat en elke Prometheus-exporter, leest datzelfde veld en zet twee samples om in een percentage.

Eén consequentie is belangrijker dan de rest. Als de hypervisor de teller nooit exporteert, blijft het veld voor altijd op nul staan en rapporteert elke tool die hierop is gebaseerd een rustige 0.0, terwijl de host overbelast is. KVM en Xen exporteren het wel. Guests op VMware en Hyper-V rapporteren doorgaans een constante nul. Controleer het platform voordat u een nul vertrouwt:

systemd-detect-virt

Dit drukt de platformnaam af, zoals kvm, xen, vmware of microsoft, en none op bare metal. Binnen een container rapporteert het in plaats daarvan de runtime, zoals lxc, docker of podman, wat u informatie geeft over de container en niet over de onderliggende machine. Op kvm is een nul een reëel bewijs dat de host u goed behandelt. Op een platform dat het veld nooit invult, is een nul helemaal geen bewijs en moet de belasting worden beoordeeld door de uitvoeringstijd van werkelijke taken te meten.

Hoe controleer ik CPU steal time op een VPS?

vmstat is onderdeel van het procps-pakket. Het is aanwezig op vrijwel elke Ubuntu- en Debian VPS-image, maar ontbreekt in sommige minimale container-images; installeer het daarom voordat u ervan afhankelijk bent.

sudo apt-get update
sudo apt-get install -y procps
vmstat --version
vmstat 1 5

vmstat --version drukt een regel af zoals vmstat from procps-ng 4.0.4. Als dit lukt, is de tool geïnstalleerd en leest u actuele kernel-tellers uit. vmstat 1 5 neemt vervolgens vijf keer per seconde een sample.

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 3216484  98304 1284360    0    0     4    18   62  110  3  1 96  0  0  0
 2  0      0 3216232  98304 1284360    0    0     0     0  248  431  6  2 84  0  8  0

Zoek de kolom st in het blok cpu aan de rechterkant. Huidige procps-ng-builds drukken er een gu-kolom achter voor KVM-gasttijd, waardoor st niet de laatste, maar de voorlaatste kolom is. Lees de kolom af op basis van de koptekst, aangezien de positie tussen releases is gewijzigd.

Twee gewoontes zorgen voor een betrouwbare meting. De eerste dataregel is het gemiddelde sinds het opstarten, dus negeer deze en lees de regels daarna. Eén sample is bovendien geen meting, omdat steal in pieken optreedt: voer vmstat 1 60 uit en observeer een volledige minuut voordat u een conclusie trekt.

top rapporteert hetzelfde getal op de samenvattingsregel %Cpu(s), in het veld gemarkeerd als st:

%Cpu(s):  6.2 us,  2.1 sy,  0.0 ni, 83.9 id,  0.0 wa,  0.0 hi,  0.3 si,  7.5 st

Voeg voor details per core sysstat toe:

sudo apt-get install -y sysstat
mpstat -P ALL 1 5

mpstat drukt één rij per CPU af met een %steal-kolom, die laat zien of elke vCPU wordt beïnvloed of slechts één. Voor de historie die een supportticket vereist, kunt u de samples beter opslaan dan ze van het scherm aflezen:

date -u | tee -a ~/steal.log
mpstat -P ALL 1 5 | tee -a ~/steal.log

Voer dit via cron uit gedurende de uren waarin u problemen vermoedt. Het bestand vormt dan het verschil tussen tegen een provider zeggen "het voelde gisteravond traag" en het aantonen van de exacte tien minuten.

Wat betekenen de steal-cijfers?

• Een stabiele 0.0. Gezond, of het platform rapporteert helemaal geen steal. Controleer dit met systemd-detect-virt voordat u conclusies trekt.
• Pieken van enkele procenten die seconden aanhouden. Normaal op elke gedeelde node. Een build van een buurman start, of de host voert back-ups uit.
• 1 tot 5 procent aanhoudend op een gedeeld abonnement. Verwacht. De prijs weerspiegelt het gebruik van gedeelde CPU-capaciteit.
• 5 tot 10 procent aanhoudend. Een vertraging die u kunt meten. Begin met het verzamelen van bewijs en vergelijk dezelfde uren over meerdere dagen.
• Langer dan enkele uren boven de 10 procent. De node is overbezet voor uw workload. Dit is het niveau waarop een supportticket of een verhuizing gerechtvaardigd is.

Beschouw deze marges als een leeswijzer in plaats van een specificatie, aangezien geen enkele provider een steal-garantie biedt op een gedeeld abonnement. Weeg ze af tegen wat u draait. Een batch-job die 's nachts draait, kan 15 procent steal opvangen zonder dat iemand het merkt. Een latency-gevoelige service laat dit in de p99 zien lang voordat het gemiddelde alarmerend oogt; daarom horen latency-gevoelige workloads zoals handelsbots thuis op dedicated cores.

Wat kost steal time u?

De berekening is kort. Als een fractie s van uw CPU-tijd wordt ingenomen, duurt een taak die een vaste hoeveelheid CPU vereist 1 / (1 - s) keer zo lang in de praktijk. Voor een taak die 60 seconden CPU nodig heeft:

[
  {
    "steal_percent": 0,
    "wall_clock_seconds": "60.0"
  },
  {
    "steal_percent": 3,
    "wall_clock_seconds": "61.9"
  },
  {
    "steal_percent": 8,
    "wall_clock_seconds": "65.2"
  },
  {
    "steal_percent": 15,
    "wall_clock_seconds": "70.6"
  },
  {
    "steal_percent": 25,
    "wall_clock_seconds": "80.0"
  },
  {
    "steal_percent": 40,
    "wall_clock_seconds": "100.0"
  }
]

Bij 3 procent, een gebruikelijke waarde voor een gedeeld abonnement, duurt die taak 61.9 seconden in plaats van 60.0. Niemand opent hiervoor een ticket. Bij 8 procent is dit 65.2 seconden. Bij 40 procent heeft dezelfde taak 100.0 seconden nodig, en een wachtrij die voorheen leegliep, begint nu te groeien.

Dit zijn berekende waarden, geen metingen. Het model gaat uit van een enkele uitvoerbare thread en een gelijkmatige verdeling van steal over het interval. Echte services voelen vaak trager aan dan de curve suggereert, omdat een gestolen slice midden in een verzoek valt en de vertraging vervolgens opnieuw wordt betaald door alles wat op dat verzoek wacht. Om uw eigen cijfer te krijgen in plaats van een formule, kunt u de VPS benchmarken tijdens een rustig uur en opnieuw tijdens een druk uur, waarbij u voor beide vensters st registreert.

Is het steal, of is er iets anders aan de hand?

Steal is gemakkelijk te verwarren met andere symptomen. Lees de tellers samen af, op dezelfde vmstat regel.

• st hoog terwijl r en us laag blijven: de host stelt de core niet aan u beschikbaar. Dat is steal.
• r ruim boven uw aantal vCPU's, met us hoog en st nabij nul: u voert meer werk uit dan uw eigen CPU's kunnen verwerken. Vergelijk r met de uitvoer van nproc. Dit is uw eigen overboeking, niet die van een buurman.
• wa hoog met st nabij nul: taken zijn geblokkeerd door opslag, wat een ander probleem is met een andere oplossing.
• Load average hoog terwijl st en us beide laag zijn: het load-cijfer telt ook niet-onderbreekbare taken mee, dus dit wijst meestal op een vastgelopen apparaat of een hangende netwerk-mount in plaats van op de CPU.

Burstable-abonnementen verdienen een eigen opmerking. Deze geven u een kredietsaldo dat wordt opgebouwd terwijl u inactief bent en verbruikt wordt terwijl u bezig bent; wanneer dit op is, houdt de provider u op een basisniveau. Op sommige platforms wordt die throttling gerapporteerd als steal. Op andere is het van binnenuit onzichtbaar en krijgt u simpelweg minder cycli per seconde. Lees de beschrijving van het abonnement voordat u concludeert dat een buurman de oorzaak is.

Waarom een container geen steal time rapporteert

Steal is een eigenschap van de virtuele machine, niet van een container die daarin draait. Een Docker-container op uw eigen VPS deelt de /proc van de host, dus een st-waarde die daarbinnen wordt uitgelezen is de steal van de VPS zelf; dit is wat u wilt zien. Containergebaseerde virtualisatie die als VPS wordt verkocht, gedraagt zich anders. Met lxcfs actief wordt /proc/stat binnen de container gesynthetiseerd op basis van cgroup-accounting, en is de steal door de constructie altijd nul. Een monitoringstack die alleen gegevens van binnenuit verzamelt, kan een vlakke, rustige nul tonen terwijl de onderliggende fysieke machine overbelast is.

Binnen een container is de teller met dezelfde betekenis de CPU-quota throttling. Op cgroup v2:

cat /sys/fs/cgroup/cpu.stat

nr_throttled telt de handhavingsperioden waarin de groep zijn CPU-quota bereikte, en throttled_usec telt de totale tijd dat het proces bevroren was. Een stijgende nr_throttled betekent dat uw proces klaar was om te draaien maar niet werd uitgevoerd; dit is dezelfde ervaring als steal, maar veroorzaakt door een limiet die u zelf heeft ingesteld. Controleer uw eigen limieten voordat u de host de schuld geeft, zeker als u uw services in Docker op een VPS draait met CPU-limieten in het compose-bestand. Gelaagde virtualisatie voegt nog een plek toe waar tijd verloren kan gaan, omdat een VM binnen uw VPS zowel uw steal als de eigen scheduling-vertraging ondervindt. Houd hier rekening mee als u geneste virtualisatie op een VPS draait.

Wat te doen bij aanhoudende steal

Geen enkele instelling binnen de guest lost steal op, omdat de scheduler die de beslissing neemt buiten de guest draait. Het upgraden van de kernel verandert daar niets aan: de cache-aware scheduling toegevoegd in Linux kernel 7.2 herschikt uw taken over de cores die u daadwerkelijk heeft gekregen, en kan de cycli die een buurman al heeft verbruikt niet herstellen. Er zijn vier reële stappen.

Verzamel eerst bewijs. Noteer tijdstippen in UTC, de duur van elke episode, hoe vaak deze zich herhaalt en of mpstat laat zien dat één vCPU wordt beïnvloed of allemaal. Een week aan gelogde samples is waardevoller dan een screenshot.

Open een ticket met die gegevens. Stel twee directe vragen: is deze node oversubscribed tijdens deze vensters, en kan mijn instance worden verplaatst? Plak de vmstat output en de exacte tijden erbij. Providers ondernemen actie op basis van een reproduceerbaar venster; een ticket dat alleen stelt dat de server traag is, krijgt als antwoord het verzoek om bewijs. Hoeveel van dit werk u kunt uitbesteden, is een van de praktische verschillen tussen een managed en een unmanaged VPS.

Vraag om een migratie. Het verplaatsen van een guest naar een minder zwaar belaste node is routinewerk voor een provider en betreft meestal een korte reboot. Dit is de oplossing die niets kost en het lost het meest voorkomende scenario op, waarbij één node toevallig meerdere zware buren tegelijkertijd huisvest.

Koop de contention af. Een dedicated vCPU-plan reserveert fysieke cores voor uw instance, waardoor de teller op nul staat en blijft. Dit kost maandelijks meer, maar het is het eerlijke antwoord voor een workload die de variantie niet kan opvangen. Als dat nog steeds niet genoeg is, of als u ook de geheugenbandbreedte voor uzelf wilt, is de volgende stap een dedicated server in plaats van een VPS.

Terwijl u op een van deze oplossingen wacht, kunt u de impact van steal verminderen. Draai minder worker-threads dan u vCPU's heeft, omdat threads die geen core kunnen krijgen alleen maar zorgen voor extra context switches. Verplaats batchwerk naar de uren waarop de node rustig is, wat uw eigen logboek u inmiddels vertelt. Meet daarna opnieuw met hetzelfde commando over dezelfde uren, zodat u kunt vaststellen of de wijziging heeft gewerkt in plaats van te gissen.

FAQ

Wat is een normale CPU steal time op een VPS?

Op een gedeeld abonnement zijn korte pieken en een aanhoudende waarde onder de 5 procent normaal, omdat bij gedeelde CPU's de host fysieke cores verdeelt tussen gastsystemen. Aanhoudende dubbele cijfers gedurende meerdere uren zijn niet normaal en vormen een reden voor een supportticket. Op een abonnement met dedicated vCPU's is de verwachte waarde 0.0; elke andere waarde is een fout die gemeld moet worden. Beoordeel het getal op basis van uw eigen werklast: een batchtaak die 's nachts draait, kan steal opvangen die een latency-gevoelige API niet kan verdragen.

Lost een groter abonnement een hoge steal time op?

Niet vanzelf. Meer vCPU's op dezelfde gedeelde node betekent meer virtuele CPU's die strijden om dezelfde fysieke cores, en het percentage kan precies gelijk blijven. Wat steal wegneemt, is een dedicated CPU-toewijzing of een verhuizing naar een minder zwaar belaste node. Een groter aandeel van een drukke machine blijft een aandeel van een drukke machine.

Waarom toont mijn VPS 0 steal time terwijl hij duidelijk traag is?

Er zijn twee veelvoorkomende redenen. De hypervisor exporteert de teller mogelijk helemaal niet, wat gebruikelijk is bij VMware- en Hyper-V-platformen, waardoor het veld op nul blijft staan ongeacht wat de host doet. Voer systemd-detect-virt uit om te zien op welk platform u zich bevindt. Anders ligt de bottleneck elders: controleer wa op opslagwachttijden, vergelijk r met nproc voor uw eigen overbelasting, en lees /sys/fs/cgroup/cpu.stat binnen containers voor quota-throttling.

Kan ik steal time verminderen vanuit mijn server?

U kunt de scheduling van de host niet aanpassen vanuit de gastomgeving. U kunt alleen de impact ervan verminderen. Draai minder worker-threads dan u vCPU's heeft, zodat er minder werk in de run queue staat te wachten op een core die niet beschikbaar komt. Verplaats batchtaken naar uren waarop de node rustiger is. Cache resultaten zodat minder verzoeken CPU-kracht vereisen. De wijzigingen die steal daadwerkelijk wegnemen, zoals een migratie naar een andere node of dedicated cores, liggen aan de kant van de provider.