CPU steal time sa VPS: noisy neighbour ba ito?

Ano talaga ang sinusukat ng CPU steal time

Ang CPU steal time ay bahagi ng oras na handang tumakbo ang iyong virtual CPU at wala itong hinihintay, pero ibinigay ng hypervisor ang physical core sa ibang guest. Naka-queue ang workload. Ginagamit ang core sa ibang guest. Hiwalay na binibilang ng Linux ang mga cycle na iyon at iniuulat bilang st. Dahil dito, matutukoy mo kung “busy ang server ko” o “hinihintay ng server ko ang turn nito.”

Iyan ang pangunahing dahilan kung bakit umiiral ang counter na ito. Ang oras na ginugugol ng sarili mong mga process sa CPU ay iniuulat bilang us (user) o sy (system). Ang oras na naka-block ang isang task habang naghihintay sa storage ay iniuulat bilang wa (I/O wait). Ang vCPU (virtual CPU) na runnable, nasa run queue, walang hinihintay na I/O, pero hindi pa rin nag-e-execute, ay iniuulat bilang st. Walang anuman sa loob ng iyong server ang makakapag-clear sa estadong ito, dahil ginagawa ang scheduling decision isang layer sa ibaba mo, sa host.

Direktang nauugnay ito sa kung paano naghahati ng isang physical machine ang VPS sa maraming guest. Karaniwang sanhi nito ang isang kapitbahay na guest: mataas ang load ng ibang guest sa parehong node, kaya hinahati ng host ang mga core sa pagitan ninyo. May isa pang sanhi na madalas hindi napapansin. Nililimitahan ng maraming provider ang shared vCPU sa isang bahagi ng physical core, at sa ilang hypervisor, ang ipinapatupad na limitasyong ito ay binibilang bilang steal sa loob ng guest. Kaya ipinapakita ng mataas na st na reading na hindi ibinigay sa iyo ang core. Hindi nito palaging ipinapakita kung sino ang gumamit nito.

Saan nanggagaling ang steal number

Hindi kayang sukatin ng kernel ang steal nang mag-isa dahil hindi nito nakikita ang host. Ang hypervisor ang nagbibigay ng value nito. Sa KVM, nagsusulat ang host ng per-vCPU counter sa isang page na shared sa guest, at ina-add ito ng guest kapag ang kernel ay bina-build gamit ang CONFIG_PARAVIRT_TIME_ACCOUNTING, na kasama sa kernel ng bawat distribution. Inirereport ng Xen ang parehong value sa pamamagitan ng runstate area nito. Sa iisang lugar lang eksaktong napupunta ang total sa userspace:

head -1 /proc/stat

Ang cpu line na iyon ay naglalaman ng sampung counter, na nasa USER_HZ ticks mula nang mag-boot, sa ganitong pagkakasunod-sunod: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. Ang steal ay ang ikawalong value pagkatapos ng label. Binabasa ng bawat tool sa ibaba, vmstat, top, mpstat, at ng anumang Prometheus exporter ang parehong field at ginagawang percentage ang dalawang sample.

Mas mahalaga kaysa sa iba ang isang epekto nito. Kung hindi kailanman ini-export ng hypervisor ang counter, mananatili sa zero ang field magpakailanman, at magrereport ang bawat tool na nakabatay rito ng kalmadong 0.0 kahit overloaded ang host. Ini-export ito ng KVM at Xen. Karaniwang flat zero ang nire-report ng mga guest sa VMware at Hyper-V. Suriin ang platform bago ka magtiwala sa zero:

systemd-detect-virt

Ipinapakita nito ang pangalan ng platform, gaya ng kvm, xen, vmware, o microsoft, at none kapag bare metal. Sa loob ng container, runtime naman ang inirereport nito, gaya ng lxc, docker, o podman. Sinasabi nito ang tungkol sa container at hindi tungkol sa machine sa ilalim nito. Sa kvm, totoong ebidensiya na maayos ang pakikitungo ng host sa iyo ang zero. Sa platform na hindi kailanman naglalagay ng value sa field, walang ebidensiya ang zero, at kailangang suriin ang contention sa pamamagitan ng timing ng aktuwal na gawain.

Paano susuriin ang CPU steal time sa isang VPS?

Ang vmstat ay bahagi ng procps package. Nasa halos lahat ng Ubuntu at Debian VPS image ito, ngunit wala ito sa ilang minimal container image. I-install ito bago ito gawing dependency.

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

Nagpi-print ang vmstat --version ng linyang gaya ng vmstat from procps-ng 4.0.4. Kapag may na-print ito, naka-install ang tool at nagbabasa ka ng aktuwal na kernel counter. Pagkatapos, kumukuha ang vmstat 1 5 ng isang sample bawat segundo, nang limang beses.

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

Hanapin ang column na st sa cpu block sa kanan. Sa kasalukuyang procps-ng build, nagpi-print ito ng column na gu pagkatapos nito para sa KVM guest time. Kaya ang st ay pangalawa mula sa kanan at hindi ang pinakahuli. Basahin ang column batay sa header name nito, dahil nagbago ang posisyong iyon sa pagitan ng mga release.

May dalawang gawain na makatutulong para maging tama ang pagbasa. Ang unang data line ay average mula nang mag-boot ang system, kaya huwag itong isama at basahin ang mga kasunod na line. Hindi rin sapat ang isang sample bilang measurement dahil dumarating nang maramihan ang steal time. Patakbuhin ang vmstat 1 60 at i-monitor ito nang isang buong minuto bago gumawa ng konklusyon.

Iniuulat ng top ang parehong value sa %Cpu(s) summary line nito, sa field na may markang 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

Para sa detalye ng bawat core, idagdag ang sysstat:

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

Nagpi-print ang mpstat ng isang row para sa bawat CPU, kasama ang %steal column. Ipinapakita nito kung lahat ng vCPU ay apektado o isa lamang. Para sa history na kailangan sa support ticket, i-save ang mga sample sa halip na basahin lamang ang mga ito sa screen:

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

Patakbuhin ito mula sa cron sa mga oras na pinaghihinalaan mong may problema. Sa ganitong paraan, magkakaroon ka ng eksaktong sampung minuto ng data sa halip na sabihin lamang sa provider na “mabagal ito kagabi.”

Ano ang ibig sabihin ng mga steal number?

• Isang tuloy-tuloy na 0.0. Healthy ito, o hindi talaga nagrereport ang platform ng steal. Kumpirmahin muna gamit ang systemd-detect-virt bago magdiwang.
• Mga spike na ilang porsiyento at tumatagal nang ilang segundo. Normal ito sa anumang shared node. Maaaring nagsimula ang build ng ibang tenant, o nagpapatakbo ng backup ang host.
• 1 hanggang 5 porsiyentong tuloy-tuloy sa isang shared plan. Inaasahan ito. Ang shared CPU ang dahilan ng presyong binabayaran.
• 5 hanggang 10 porsiyentong tuloy-tuloy. May slowdown na maaari mong sukatin. Magsimulang magtala ng ebidensiya at ikumpara ang parehong oras sa loob ng ilang araw.
• Higit sa 10 porsiyento nang ilang oras. Sobra ang load ng node para sa workload mo. Ito ang antas na nagbibigay-katwiran sa paggawa ng support ticket o paglipat ng server.

Gamitin ang mga antas na ito bilang gabay sa pagbasa, hindi bilang specification, dahil walang provider na naglalathala ng garantiya para sa steal sa isang shared plan. Isaalang-alang ito batay sa mga workload na pinapatakbo mo. Kayang tiisin ng isang overnight batch job ang 15 porsiyentong steal nang hindi ito napapansin. Makikita naman ito sa p99 ng latency-sensitive service bago pa maging nakababahala ang average. Kaya ang latency-sensitive workloads gaya ng mga trading bot ay dapat ilagay sa dedicated cores.

Ano ang halaga ng steal time para sa iyo?

Maikli ang arithmetic. Kung s ng CPU time mo ang ginagamit ng ibang tenant, ang isang job na nangangailangan ng nakapirming dami ng CPU ay tatagal ng 1 / (1 - s) beses sa wall-clock time. Para sa job na nangangailangan ng 60 segundo ng CPU:

[
  {
    "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"
  }
]

Sa 3 porsiyento, na karaniwang nakikita sa shared plan, tatagal ang job ng 61.9 segundo sa halip na 60.0. Walang magbubukas ng ticket dahil dito. Sa 8 porsiyento, aabot ito sa 65.2 segundo. Sa 40 porsiyento, mangangailangan ang parehong job ng 100.0 segundo, at magsisimulang dumami ang laman ng queue na dati ay nauubos agad.

Mga nakalkulang value ang mga ito, hindi mga measurement. Ipinapalagay ng model na iisa ang runnable thread at pantay ang pagkakakalat ng steal sa buong interval. Sa mga totoong serbisyo, kadalasan ay mas malala ang epekto kaysa sa ipinapakita ng curve, dahil maaaring mangyari ang pagkuha ng CPU slice sa gitna ng isang request. Kailangang pagbayaran muli ang delay ng lahat ng naghihintay sa request na iyon. Para makuha ang sarili mong value sa halip na gumamit ng formula, i-benchmark ang VPS sa tahimik na oras at muli sa abalang oras, habang itinatala ang st para sa dalawang window.

Steal ba ito, o iba?

Madaling mapagkamalang ibang sintomas ang steal. Basahin nang magkakasama ang mga counter sa iisang vmstat line.

• Mataas ang st habang mababa ang r at us: hindi ibinibigay ng host sa iyo ang core. Iyan ang steal.
• Mas mataas nang malaki ang r kaysa sa bilang ng iyong vCPU, mataas ang us, at halos zero ang st: mas marami ang workload kaysa sa kayang iproseso ng sarili mong CPU. Ihambing ang r sa output ng nproc. Sarili mong oversubscription ito, hindi problema ng katabing tenant.
• Mataas ang wa habang halos zero ang st: naka-block ang mga task sa storage. Ibang problema ito at ibang remediation ang kailangan.
• Mataas ang load average habang parehong mababa ang st at us: kasama rin sa load figure ang mga uninterruptible task. Karaniwan itong tumutukoy sa naka-stuck na device o nag-hang na network mount, hindi sa CPU.

Nangangailangan ng hiwalay na paliwanag ang mga burstable plan. May credit balance ang mga ito na nadaragdagan kapag idle ka at nababawasan kapag busy ka. Kapag naubos ito, nililimitahan ka ng provider sa baseline rate. Sa ilang platform, iniuulat bilang steal ang throttling na ito. Sa iba naman, hindi ito nakikita mula sa loob at mas kaunting cycle bawat segundo ang natatanggap mo. Basahin muna ang paglalarawan ng plan bago ipagpalagay na may kasalanan ang katabing tenant.

Bakit walang steal time na iniuulat ang container

Ang steal ay property ng virtual machine, hindi ng container na tumatakbo sa loob nito. Ang Docker container sa sarili mong VPS ay gumagamit ng host na /proc, kaya ang halagang st na binasa sa loob nito ay steal ng VPS, na siyang kailangan mo. Iba ang pag-uugali ng container-based virtualisation na ibinebenta bilang VPS. Kapag may lxcfs, ang /proc/stat sa loob ng container ay binubuo mula sa cgroup accounting, kaya zero ang steal ayon sa disenyo. Maaaring magpakita ang monitoring stack na kumukuha lamang ng data mula sa loob ng container ng tuloy-tuloy at kalmadong zero kahit kapos sa CPU ang pisikal na machine sa ilalim nito.

Sa loob ng container, ang counter na may kaparehong kahulugan ay CPU quota throttling. Sa cgroup v2:

cat /sys/fs/cgroup/cpu.stat

Binibilang ng nr_throttled ang mga enforcement period kung kailan naabot ng group ang CPU quota nito, at tinatala ng throttled_usec ang kabuuang oras na na-freeze ito. Kapag tumataas ang nr_throttled, nangangahulugan itong runnable ang process mo pero hindi ito tumatakbo. Pareho itong karanasan sa steal, ngunit sanhi ito ng limitasyong ikaw mismo ang nagtakda. Suriin muna ang sarili mong mga limit bago sisihin ang host, lalo na kung pinapatakbo mo ang mga serbisyo mo sa Docker sa isang VPS na may CPU limits sa compose file. Nagdaragdag ang layered virtualisation ng isa pang lugar kung saan maaaring mawala ang oras, dahil binabayaran ng VM sa loob ng VPS ang steal nito at ang sarili nitong scheduling delay. Isaisip ito kung nagpapatakbo ka ng nested virtualisation sa isang VPS.

Ano ang gagawin kapag tuloy-tuloy ang steal

Walang setting sa loob ng guest ang makapag-aayos ng steal, dahil ang scheduler na gumagawa ng desisyon ay tumatakbo sa labas ng guest. Hindi rin ito mababago ng pag-upgrade ng kernel: ang cache aware scheduling na idinagdag sa Linux kernel 7.2 ay nag-aayos ng iyong mga task sa mga core na aktuwal na inilaan sa iyo, at hindi nito maibabalik ang mga cycle na kinuha na ng katabing guest. Apat ang praktikal na hakbang.

Mangolekta muna ng ebidensiya. Itala ang mga timestamp sa UTC, ang tagal ng bawat episode, kung gaano ito kadalas umuulit, at kung ipinapakita ng mpstat na isang vCPU lamang ang apektado o lahat ng ito. Mas kapaki-pakinabang ang isang linggo ng naka-log na sample kaysa sa isang screenshot.

Magbukas ng ticket gamit ang datos na iyon. Magtanong nang direkta: overloaded ba ang node sa mga oras na ito, at maaari bang ilipat ang instance ko. Isama ang output ng vmstat at ang eksaktong mga oras. Kumakilos ang provider kapag reproducible ang window, at ang ticket na nagsasabing mabagal lang ang server ay sasagutin ng hiling para sa mga detalyeng ito. Kung gaano karami sa gawaing ito ang maaari mong ipagawa sa provider ay isa sa mga praktikal na pagkakaiba sa pagitan ng managed at unmanaged VPS.

Humiling ng migration. Karaniwang gawain ng provider ang paglipat ng guest sa node na mas kaunti ang load, at kadalasan ay maikling reboot lamang ang kailangan. Wala itong dagdag na gastos, at nalulutas nito ang karaniwang sitwasyon kung saan nagkataong nasa iisang node ang maraming mabibigat na katabing guest.

Bumili ng planong walang contention. Naglalaan ang dedicated vCPU plan ng mga physical core para sa iyong instance, kaya nananatili sa zero ang counter. Mas mataas ang buwanang gastos nito, at ito ang tamang sagot para sa workload na hindi kayang tiisin ang ganitong pagbabago-bago. Kung hindi pa rin sapat iyon, o gusto mo ring ikaw lamang ang gumamit ng memory bandwidth, ang susunod na hakbang ay dedicated server sa halip na VPS.

Habang hinihintay mo ang alinman sa mga hakbang na ito, bawasan ang epekto ng steal. Magpatakbo ng mas kaunting worker thread kaysa sa dami ng iyong vCPU, dahil nagdaragdag lamang ng context switch ang mga thread na hindi makakuha ng core. Ilipat ang batch work sa mga oras na tahimik ang node, batay sa ipinapakita ngayon ng sarili mong log. Pagkatapos, magsukat muli gamit ang parehong command sa parehong mga oras, upang matukoy kung gumana ang pagbabago sa halip na manghula.

FAQ

Ano ang normal na CPU steal time sa isang VPS?

Sa shared plan, pangkaraniwan ang maiikling spike at tuloy-tuloy na value na mas mababa sa humigit-kumulang 5 percent, dahil ang shared CPU ay nangangahulugang hinahati ng host ang mga physical core sa pagitan ng mga guest. Hindi pangkaraniwan ang tuloy-tuloy na double-digit na value sa loob ng ilang oras, kaya dapat itong i-report sa pamamagitan ng ticket. Sa dedicated vCPU plan, ang inaasahang reading ay 0.0, kaya anumang ibang value ay fault na dapat i-report. Ihambing ang value sa sarili mong workload: kayang saluhin ng overnight batch job ang steal time na hindi kayang tiisin ng latency-sensitive API.

Aayusin ba ng mas malaking plan ang mataas na steal time?

Hindi kung iyon lang ang babaguhin. Ang pagdagdag ng vCPU sa parehong shared node ay nangangahulugang mas maraming virtual CPU ang nakikipagkumpitensya para sa parehong physical core na may contention, kaya maaaring manatiling eksaktong ganoon ang percentage. Ang nag-aalis ng steal time ay dedicated CPU allocation o paglipat sa node na mas kaunti ang load. Ang mas malaking bahagi ng isang abalang machine ay bahagi pa rin ng isang abalang machine.

Bakit 0 ang steal time na ipinapakita ng VPS ko kahit malinaw na mabagal ito?

May dalawang karaniwang dahilan. Maaaring hindi talaga ine-export ng hypervisor ang counter, na karaniwan sa mga VMware at Hyper-V platform, kaya nananatiling zero ang field anuman ang ginagawa ng host. Patakbuhin ang systemd-detect-virt upang makita kung anong platform ang ginagamit mo. Kung hindi iyon ang dahilan, nasa ibang bahagi ang bottleneck: suriin ang wa para sa mga storage wait, ihambing ang r sa nproc para sa sarili mong overload, at basahin ang /sys/fs/cgroup/cpu.stat sa loob ng mga container para sa quota throttling.

Maaari ko bang bawasan ang steal time mula sa loob ng server ko?

Hindi mo mababago ang scheduling ng host mula sa loob ng guest. Maaari mo lamang bawasan ang epekto nito. Magpatakbo ng mas kaunting worker thread kaysa sa bilang ng vCPU mo, upang mas kaunting trabaho ang manatili sa run queue habang naghihintay ng core na hindi dumarating. Ilipat ang mga batch job sa mga oras na mas tahimik ang node. I-cache ang mga resulta upang mas kaunting request ang mangailangan ng CPU. Ang mga pagbabagong talagang nag-aalis ng steal time—paglipat sa ibang node o paggamit ng dedicated core—ay kailangang gawin sa panig ng provider.