CPU steal time sa VPS: noisy neighbour ba o overload?

Ano talaga ang sinusukat ng CPU steal time

Ang CPU steal time ay bahagi ng oras kung kailan handa nang tumakbo ang iyong virtual CPU at wala itong hinihintay, ngunit ibinigay ng hypervisor ang physical core sa ibang guest. Naka-queue ang work. Ginagamit ang core sa ibang lugar. Hiwalay na binibilang ng Linux ang mga cycle na ito at iniuulat bilang st. Sa ganitong paraan, matutukoy mo kung busy ang server mo o naghihintay lamang ito ng pagkakataong tumakbo.

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 nakabinbing I/O, ngunit hindi pa rin nag-e-execute, ay iniuulat bilang st. Walang anumang bahagi sa loob ng server mo ang makakapag-alis sa state na 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 para sa maraming guest. Karaniwang sanhi nito ang isang neighbour: masinsinang tumatakbo ang 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 isang shared vCPU sa bahagi lamang ng isang physical core, at sa ilang hypervisor, ina-account ang ipinapatupad na limitasyong ito bilang steal sa loob ng guest. Kaya ipinapakita ng mataas na st reading na hindi ibinigay sa iyo ang core. Hindi nito palaging ipinapakita kung sino ang gumamit nito.

Kung saan nagmumula ang steal number

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

head -1 /proc/stat

Naglalaman ang cpu line na iyon 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 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 ang isang epekto kaysa sa iba. Kung hindi ine-export ng hypervisor ang counter, mananatiling zero ang field magpakailanman, at mag-uulat 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 iniuulat 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 ang none kapag bare metal. Sa loob ng container, runtime naman ang iniuulat nito, gaya ng lxc, docker o podman, kaya impormasyon ito tungkol sa container at hindi tungkol sa machine sa ilalim nito. Sa kvm, tunay na ebidensya ang zero na maayos kang hinahandle ng host. Sa platform na hindi kailanman nagsusulat sa field, walang anumang ebidensya ang zero, at kailangang tasahin ang contention sa pamamagitan ng pag-time sa totoong work.

Paano ko susuriin ang CPU steal time sa isang VPS?

Ang vmstat ay bahagi ng package na procps. Karaniwan itong kasama sa halos lahat ng Ubuntu at Debian VPS image, pero maaaring wala sa ilang minimal container image. I-install ito bago mo ito gamitin bilang 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. Kung may lumabas na ganoon, 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 block na cpu sa kanan. Sa mga kasalukuyang procps-ng build, may column na gu pagkatapos nito para sa KVM guest time. Kaya ang st ay pangalawa mula sa kanan, hindi ang pinakahuli. Basahin ang column ayon sa header name nito, dahil nagbago ang posisyon nito sa iba’t ibang release.

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

Iniuulat ng top ang parehong value sa summary line nitong %Cpu(s), 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 bawat core, idagdag ang sysstat:

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

Nagpi-print ang mpstat ng isang row bawat CPU, kasama ang column na %steal. Ipinapakita nito kung lahat ng vCPU ang apektado o iisa lamang. Para sa history na kakailanganin 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, magiging malinaw sa file ang eksaktong sampung minuto, sa halip na sabihin lamang sa provider na “mabagal ito kagabi.”

Ano ang ibig sabihin ng mga steal number?

• Isang steady na 0.0. Healthy ito, o hindi talaga nagre-report ng steal ang platform. Kumpirmahin gamit ang systemd-detect-virt bago magdiwang.
• Mga spike na ilang porsiyento at tumatagal nang ilang segundo. Normal ito sa anumang shared node. Nagsimula ang build ng katabing tenant, o nagpapatakbo ng backup ang host.
• 1 hanggang 5 porsiyentong tuloy-tuloy sa isang shared plan. Inaasahan ito. Shared CPU ang katumbas ng presyong binabayaran.
• 5 hanggang 10 porsiyentong tuloy-tuloy. May slowdown na masusukat. Magsimulang magtala ng ebidensya at paghambingin ang parehong oras sa loob ng ilang araw.
• Higit sa 10 porsiyento nang ilang oras. Oversubscribed ang node para sa workload mo. Ito ang antas na nagbibigay-katwiran sa pag-submit ng support ticket o paglipat.

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

Magkano ang halaga ng steal time para sa iyo?

Maikli ang kalkulasyon. Kung ang fraction s ng CPU time mo ay kinukuha, ang isang job na nangangailangan ng nakapirming CPU time ay tatagal nang 1 / (1 - s) beses na mas matagal ayon sa wall clock. Para sa job na nangangailangan ng 60 segundo ng CPU time:

[
  {
    "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 percent, na karaniwang nakikita sa shared plan, tatagal ang job nang 61.9 segundo sa halip na 60.0. Walang magbubukas ng ticket para rito. Sa 8 percent, aabot ito sa 65.2 segundo. Sa 40 percent, mangangailangan ang parehong job ng 100.0 segundo, at ang queue na dati ay nauubos ay magsisimulang humaba.

Mga nakalkulang value ang mga iyon, hindi mga measurement. Ipinapalagay ng model na iisang runnable thread lang ang ginagamit at pantay ang pagkakakalat ng steal sa buong interval. Sa aktuwal na serbisyo, madalas ay mas malala ang epekto kaysa sa ipinapakita ng curve, dahil maaaring mangyari ang pagkuha ng CPU slice sa kalagitnaan ng isang request. Kailangang pagbayaran muli ng lahat ng naghihintay sa request na iyon ang delay. 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, at i-record ang st para sa parehong window.

Steal ba ito, o iba?

Madaling mapagkamalan ang steal sa iba pang sintomas. Basahin ang mga counter nang magkakasama, sa iisang vmstat line.

• Mataas ang st habang mababa ang r at us: hindi ibinibigay ng host ang CPU core para sa iyo. Iyan ang steal.
• Higit na mataas ang r kaysa sa bilang ng iyong vCPU, mataas ang us, at halos zero ang st: mas marami ang pinapatakbo mong work kaysa sa kayang hawakan ng sarili mong CPU. Ihambing ang r sa output ng nproc. Sarili mong oversubscription ito, hindi problema ng ibang tenant.
• Mataas ang wa habang halos zero ang st: naka-block ang mga task sa storage. Iba itong problema at iba rin ang kinakailangang remediation.
• 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 hung network mount, hindi sa CPU.

Nangangailangan ng hiwalay na paliwanag ang mga burstable plan. May credit balance ang mga ito na nadaragdagan habang idle ka at nababawasan habang busy ka. Kapag naubos ito, nililimitahan ka ng provider sa baseline rate. Sa ilang platform, iniuulat ang throttle na ito bilang steal. Sa iba naman, hindi ito nakikita mula sa loob at mas kaunting cycles per second lang ang nakukuha mo. Basahin muna ang paglalarawan ng plan bago ipagpalagay na ibang tenant ang sanhi.

Bakit walang steal time na iniuulat ang isang 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 /proc ng host, kaya ang value ng st na binasa sa loob nito ay ang steal ng VPS. Ito ang value na kailangan mo. Iba ang asal ng container-based virtualisation na ibinebenta bilang VPS. Kapag may lxcfs, ang /proc/stat sa loob ng container ay ginagawa batay 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 na 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 naman ng throttled_usec ang kabuuang oras na naka-freeze ito. Ipinapahiwatig ng tumataas na nr_throttled na runnable ang proseso mo pero hindi ito tumatakbo. Pareho ang karanasang ito sa steal, ngunit sanhi ito ng limit na ikaw mismo ang nagtakda. Suriin muna ang sarili mong limits 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 ng isa pang lugar kung saan maaaring mawala ang oras ang layered virtualisation, dahil binabayaran ng VM sa loob ng VPS ang steal nito at ang sarili nitong scheduling delay. Tandaan ito kung gumagamit ka ng nested virtualisation sa isang VPS.

Ano ang dapat gawin sa tuloy-tuloy na steal

Walang setting sa loob ng guest ang makalulutas sa steal, dahil nasa labas ng guest tumatakbo ang scheduler na gumagawa ng desisyon. Apat ang aktuwal 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 lang o lahat ng vCPU ang apektado. Mas mahalaga ang isang linggong 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. Nakakakilos ang mga provider kapag may reproducible na time window. Kapag “mabagal ang server” lang ang nakalagay sa ticket, hihingi sila ng ganoong detalye. Ang lawak ng trabahong maaari mong ipaubaya sa provider ay isa sa praktikal na pagkakaiba ng managed at unmanaged VPS.

Humiling ng migration. Karaniwang gawain para sa provider ang paglilipat ng guest sa node na mas kaunti ang load, at kadalasan ay maikling reboot lamang ang kailangan. Ito ang solusyong walang dagdag na gastos. Nalulutas nito ang karaniwang sitwasyon kung saan nagkataong maraming mabibigat na neighbor ang nasa iisang node.

Bumili ng planong walang contention. Nagrereserba ang dedicated vCPU plan ng mga physical core para sa iyong instance, kaya nananatiling zero ang counter. Mas mahal ito bawat buwan, at ito ang tamang sagot para sa workload na hindi kayang tiisin ang ganitong variation. Kung hindi pa rin sapat iyon, o gusto mo ring ikaw lang ang gumamit ng memory bandwidth, ang susunod na hakbang ay dedicated server sa halip na VPS.

Habang hinihintay mo ang alinman sa mga iyon, bawasan ang epekto ng steal. Magpatakbo ng mas kaunting worker thread kaysa sa bilang ng iyong vCPU, dahil nagdaragdag lang 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. Sa ganitong paraan, malalaman mo kung gumana ang pagbabago sa halip na manghula.

FAQ

Ano ang normal na CPU steal time sa isang VPS?

Sa shared plan, karaniwan ang maiikling spike at sustained value na mas mababa sa humigit-kumulang 5 percent, dahil sa shared CPU ay hinahati ng host ang physical cores sa pagitan ng mga guest. Hindi karaniwan ang sustained double digits sa loob ng ilang oras at 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 na hindi kakayanin ng latency-sensitive API.

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

Hindi nang mag-isa. Ang mas maraming vCPU sa parehong shared node ay nangangahulugang mas maraming virtual CPU ang nakikipag-agawan sa parehong contended physical cores, kaya maaaring manatiling eksaktong ganoon ang percentage. Ang nag-aalis ng steal ay dedicated CPU allocation o paglipat sa node na mas kaunti ang load. Ang mas malaking share ng isang abalang machine ay share pa rin ng isang abalang machine.

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

May dalawang karaniwang dahilan. Maaaring hindi talaga ine-export ng hypervisor ang counter, na karaniwan sa VMware at Hyper-V platforms, 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, nasa ibang bahagi ang bottleneck: suriin ang wa para sa storage waits, ihambing ang r sa nproc para sa sarili mong overload, at basahin ang /sys/fs/cgroup/cpu.stat sa loob ng containers 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. Ang magagawa mo lamang ay bawasan ang epekto nito. Magpatakbo ng mas kaunting worker threads 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. Mag-cache ng mga resulta upang mas kaunting request ang mangailangan ng CPU. Ang mga pagbabagong aktuwal na nag-aalis ng steal—paglipat sa ibang node o paggamit ng dedicated cores—ay nasa panig ng provider.