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

Wat CPU steal time daadwerkelijk meet

CPU steal time is het deel 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 elders in gebruik. Linux telt deze cycli afzonderlijk en rapporteert ze als st. Hiermee kunt u het onderscheid maken tussen "mijn server is druk" 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 deze status opheffen, 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 meerdere gasten. De gebruikelijke oorzaak is een buurman: een andere gast op dezelfde node 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 bij verschillende hypervisors wordt die afgedwongen limiet binnen 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 deze 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 gevolg 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 vlakke 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 echt 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 afkomstig uit het procps-pakket. Het is aanwezig op vrijwel elke Ubuntu- en Debian VPS-image, maar ontbreekt in sommige minimale container-images; installeer het dus 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 wordt getoond, is het hulpprogramma geïnstalleerd en leest u de werkelijke kernel-tellers uit. vmstat 1 5 neemt vervolgens vijf keer één sample per seconde.

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 cpu-blok aan de rechterkant. Huidige procps-ng-builds drukken een gu-kolom af na de kolom voor KVM-gasttijd, waardoor st de tweede van rechts is in plaats van de laatste. 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 die daarna volgen. Eén sample is bovendien geen meting, omdat steal time in pieken optreedt: voer vmstat 1 60 uit en observeer een volledige minuut voordat u een conclusie trekt.

top rapporteert hetzelfde getal op de %Cpu(s)-samenvattingsregel, 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 sysstat toe voor details per core:

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 nodig is voor een supportticket, kunt u de samples beter opslaan in plaats van ze van het scherm af te lezen:

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

Voer dit uit via cron 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-waarden?

• 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.
• 5 tot 10 procent aanhoudend. Een vertraging die u kunt meten. Begin met het vastleggen 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 dat een supportticket of een verhuizing rechtvaardigt.

Beschouw deze bandbreedtes als een leeswijzer in plaats van een specificatie, aangezien geen enkele provider een steal-garantie publiceert 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 trading bots 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 steal die gelijkmatig over het interval is verdeeld. 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 st voor beide vensters registreert.

Is het steal, of is het iets anders?

Steal is gemakkelijk te verwarren met andere symptomen. Lees de tellers in samenhang, 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 output 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 ononderbreekbare 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 bieden een tegoedbalans die 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 beperking gerapporteerd als steal. Op andere is het onzichtbaar van binnenuit 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. Container-gebaseerde 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 per definitie nul. Een monitoringstack die alleen gegevens van binnenuit verzamelt, kan een vlakke, rustige nul tonen terwijl de fysieke machine eronder 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-quotum heeft bereikt, en throttled_usec sommeert de tijd die het proces bevroren is geweest. Een stijgende nr_throttled betekent dat uw proces klaar was om te draaien maar niet mocht draaien; 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 zijn eigen scheduling-vertraging betaalt. 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. Er zijn vier reële stappen.

Verzamel eerst bewijs. Noteer tijdstippen in UTC, de duur van elke episode, hoe vaak het 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 bij een reproduceerbaar venster; een ticket waarin alleen staat dat de server traag is, leidt tot een antwoord waarin om die gegevens wordt gevraagd. 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 vereist meestal slechts 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 staan. Dit kost maandelijks meer, maar 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 vCPUs heeft, omdat threads die geen core kunnen krijgen alleen maar voor extra context switches zorgen. Verplaats batchwerk naar de uren waarop de node rustig is, wat uw eigen logboek u nu 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 over 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 batch-taak 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 op zichzelf. Meer vCPU's op dezelfde gedeelde node betekent meer virtuele CPU's die strijden om dezelfde fysieke cores, waardoor het percentage exact gelijk kan 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 deze 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 het knelpunt elders: controleer wa op opslag-wachttijden, 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 wijzigen 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 batch-taken 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.