CPU steal time ni nini kwenye VPS?

Kile ambacho CPU steal time hupima kwa hakika

CPU steal time ni sehemu ya muda ambapo vCPU yako ilikuwa tayari kufanya kazi, bila kitu cha kusubiri, wakati hypervisor ilipotoa core ya kimwili kwa mgeni mwingine. Kazi hiyo ilikuwa kwenye foleni. Core ilikuwa mahali pengine. Linux huhesabu mizunguko hiyo kando na kuiripoti kama st, ambayo ndiyo njia unayotumia kutofautisha kati ya "seva yangu ina shughuli nyingi" na "seva yangu inasubiri zamu yake".

Tofauti hiyo ndiyo sababu kuu ya kuwepo kwa kaunta hii. Muda ambao michakato yako mwenyewe hutumia kwenye CPU huripotiwa kama us (user) au sy (system). Muda ambao kazi hutumia ikiwa imezuiwa kwenye hifadhi huripotiwa kama wa (I/O wait). vCPU (virtual CPU) ambayo inaweza kufanya kazi, ikiwa imekaa kwenye run queue, bila I/O inayongoja, na bado haitekelezi kazi, huripotiwa kama st. Hakuna kitu ndani ya seva yako kinachoweza kuondoa hali hiyo, kwa sababu uamuzi wa kupanga ratiba hufanywa ngazi moja chini yako, kwenye host.

Hii inatokana moja kwa moja na jinsi VPS inavyoshiriki mashine moja ya kimwili kati ya wageni wengi. Sababu ya kawaida ni jirani: mgeni mwingine kwenye node hiyo hiyo anafanya kazi kwa kasi, kwa hivyo host hugawanya cores kati yako na yeye. Kuna sababu ya pili ambayo mara nyingi husahaulika. Watoa huduma wengi huweka kikomo cha vCPU iliyoshirikiwa kwa sehemu ndogo ya core ya kimwili, na kwenye hypervisors kadhaa, kikomo hicho kilichotekelezwa huhesabiwa kama steal ndani ya mgeni. Kwa hivyo, usomaji wa juu wa st hukuambia kuwa core haikupewa wewe. Haikuambii kila wakati ni nani aliyeichukua.

Chanzo cha namba ya steal

Kernel yako haiwezi kupima steal yenyewe, kwa sababu haiwezi kuona host. Hypervisor ndiyo inayoiambia. Kwenye KVM, host huandika counter ya kila vCPU kwenye ukurasa ulioshirikiwa na guest, na guest huijumlisha wakati kernel inapojengwa ikiwa na CONFIG_PARAVIRT_TIME_ACCOUNTING, ambayo kila kernel ya distribution inayo. Xen huripoti kitu hicho hicho kupitia eneo lake la runstate. Jumla hiyo hufika kwenye userspace katika sehemu moja tu:

head -1 /proc/stat

Mstari huo wa cpu hubeba counters kumi, katika ticks za USER_HZ tangu boot, kwa mpangilio huu: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. Steal ni thamani ya nane baada ya lebo. Kila zana iliyo hapa chini, vmstat, top, mpstat na exporter yoyote ya Prometheus, husoma sehemu hiyo hiyo na kugeuza sampuli mbili kuwa asilimia.

Matokeo moja ni muhimu zaidi kuliko mengine. Ikiwa hypervisor haitoi counter hiyo, sehemu hiyo hubaki kwenye sifuri milele, na kila zana inayotegemea hiyo huripoti 0.0 tulivu wakati host imezidiwa. KVM na Xen huitoa. Guests kwenye VMware na Hyper-V mara nyingi huripoti sifuri tupu. Hakiki platform kabla ya kuamini sifuri:

systemd-detect-virt

Inachapisha jina la platform, kama vile kvm, xen, vmware au microsoft, na none kwenye bare metal. Ndani ya container inaripoti runtime badala yake, kama vile lxc, docker au podman, ambayo inakuambia kuhusu container na si kuhusu mashine iliyo chini yake. Kwenye kvm sifuri ni ushahidi halisi kwamba host inakuhudumia vizuri. Kwenye platform ambayo haijazi sehemu hiyo, sifuri si ushahidi wowote, na contention lazima ihukumiwe kwa kupima muda wa kazi halisi badala yake.

Ninawezaje kuangalia CPU steal time kwenye VPS?

vmstat inatoka kwenye kifurushi cha procps. Inapatikana kwenye karibu kila image ya VPS ya Ubuntu na Debian, na haipo kwenye baadhi ya image ndogo za container, kwa hivyo iweke kabla ya kuitumia.

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

vmstat --version huchapisha mstari kama vmstat from procps-ng 4.0.4. Ikiwa mstari huo utatokea, zana hiyo imewekwa na unasoma viashiria halisi vya kernel. vmstat 1 5 kisha huchukua sampuli moja kwa sekunde, mara tano.

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

Tafuta safu ya st katika kizuizi cha cpu upande wa kulia. Matoleo ya sasa ya procps-ng huchapisha safu ya gu baada yake kwa ajili ya muda wa KVM guest, kwa hivyo st huwa ya pili kutoka kulia badala ya kuwa ya mwisho. Soma safu hiyo kwa kutumia jina la kichwa chake, kwa sababu nafasi hiyo imebadilika kati ya matoleo.

Tabia mbili zitakusaidia kupata usomaji sahihi. Mstari wa kwanza wa data ni wastani tangu kuanza kwa seva (boot), kwa hivyo uupuuze na usome mistari inayofuata. Na sampuli moja si kipimo tosha, kwa sababu steal hutokea kwa vipindi: endesha vmstat 1 60 na uifuatilie kwa dakika nzima kabla ya kufanya hitimisho.

top huripoti namba hiyo hiyo kwenye mstari wake wa muhtasari wa %Cpu(s), katika sehemu iliyoandikwa 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

Kwa maelezo ya kila core, ongeza sysstat:

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

mpstat huchapisha mstari mmoja kwa kila CPU wenye safu ya %steal, ambayo huonyesha ikiwa kila vCPU imeathirika au moja tu. Kwa ajili ya historia inayohitajika kwenye tiketi ya usaidizi, hifadhi sampuli hizo badala ya kuzisoma kwenye skrini:

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

Endesha amri hiyo kupitia cron kwa saa unazohisi kuna tatizo, na faili hilo litakuwa tofauti kati ya kumwambia mtoa huduma "ilikuwa polepole jana usiku" na kuwaonyesha dakika kumi kamili za tatizo hilo.

Nambari za steal zinamaanisha nini?

• 0.0 thabiti. Hali ni nzuri, au mfumo hauripoti steal yoyote. Thibitisha na systemd-detect-virt kabla ya kufurahia.
• Mlipuko wa asilimia chache kwa sekunde chache. Hali ya kawaida kwenye node yoyote inayoshirikiwa. Labda ujenzi wa programu ya jirani umeanza, au mwenyeji anaendesha backups zake.
• Asilimia 1 hadi 5 kwa muda mrefu kwenye mpango wa pamoja. Hali inayotarajiwa. CPU inayoshirikiwa ndiyo inayolingana na bei unayolipa.
• Asilimia 5 hadi 10 kwa muda mrefu. Hii ni kupungua kwa kasi unayoweza kupima. Anza kurekodi ushahidi, na ulinganishe saa hizo hizo kwa siku kadhaa.
• Zaidi ya asilimia 10 kwa saa nyingi mfululizo. Node imezidiwa kwa mzigo wako wa kazi. Hii ndiyo kiwango kinachohalalisha kufungua tiketi ya msaada au kuhama.

Chukulia viwango hivyo kama mwongozo wa usomaji badala ya vipimo rasmi, kwa sababu hakuna mtoa huduma anayetoa hakikisho la steal kwenye mpango wa pamoja. Vipime kulingana na kile unachokiendesha. Kazi ya batch ya usiku inaweza kuvumilia asilimia 15 ya steal bila mtu yeyote kugundua. Huduma inayohitaji latency ndogo huonyesha tatizo kwenye p99 muda mrefu kabla ya wastani kuonekana kuwa wa kutisha, ndiyo maana mzigo wa kazi unaohitaji latency ndogo kama bots za biashara unapaswa kuwekwa kwenye cores zilizotengwa.

Je, steal time inakugharimu kiasi gani?

Hesabu yake ni fupi. Ikiwa sehemu ya s ya muda wako wa CPU inachukuliwa, kazi inayohitaji kiasi maalum cha CPU itachukua muda mrefu mara 1 / (1 - s) kwenye saa. Kwa kazi inayohitaji sekunde 60 za 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"
  }
]

Katika asilimia 3, ambayo ni usomaji wa kawaida wa shared-plan, kazi hiyo inachukua sekunde 61.9 badala ya sekunde 60.0. Hakuna anayefungua tiketi kwa ajili ya hilo. Katika asilimia 8, inachukua sekunde 65.2. Katika asilimia 40, kazi hiyo hiyo inahitaji sekunde 100.0, na foleni iliyokuwa ikimalizika inaanza kukua badala yake.

Hayo ni maadili yaliyokokotolewa, si vipimo. Mfano huu unadhani kuna thread moja inayoweza kuendeshwa na kwamba steal inasambaa sawasawa katika muda wote. Huduma za kweli mara nyingi huhisi vibaya zaidi kuliko curve hiyo, kwa sababu kipande kilichoibiwa hutokea katikati ya ombi na ucheleweshaji hulipwa tena na kila kitu kinachosubiri ombi hilo. Ili kupata takwimu zako mwenyewe badala ya fomula, fanya benchmark ya VPS wakati wa saa tulivu na tena wakati wa saa yenye shughuli nyingi, ukirekodi st kwa vipindi vyote viwili.

Je, ni steal, au ni kitu kingine?

Ni rahisi kuchanganya steal na dalili nyingine. Soma viashiria hivi kwa pamoja, kwenye mstari uleule wa vmstat.

• st iko juu wakati r na us zikiwa chini: seva pangwa (host) haikupi nguvu ya processor. Hiyo ndiyo steal.
• r iko juu sana kuliko idadi ya vCPU zako, huku us ikiwa juu na st ikiwa karibu na sifuri: unaendesha kazi nyingi kuliko uwezo wa CPU zako. Linganisha r na matokeo ya nproc. Hii ni oversubscription yako mwenyewe, siyo jirani kwenye seva.
• wa iko juu huku st ikiwa karibu na sifuri: kazi zimekwama kwenye hifadhi (storage), hili ni tatizo tofauti lenye suluhisho tofauti.
• Load average iko juu wakati st na us zote zikiwa chini: takwimu ya load huhesabu pia kazi zisizoweza kukatizwa (uninterruptible tasks), kwa hivyo hii mara nyingi huashiria kifaa kilichokwama au network mount iliyogoma, badala ya tatizo la CPU.

Mipango ya "burstable" inahitaji maelezo yake. Inakupa salio la credit ambalo hujijenga ukiwa huna kazi na kupungua ukiwa na shughuli, na likiisha, mtoa huduma anakubana kwenye kiwango cha chini cha kasi (baseline rate). Kwenye mifumo mingine, ubanaji huo huripotiwa kama steal. Kwenye mingine, haionekani kutoka ndani, na unapata tu mizunguko michache ya CPU kwa sekunde. Soma maelezo ya mpango wako kabla ya kuhitimisha kuwa jirani kwenye seva ndiye mwenye makosa.

Kwa nini container haionyeshi steal time

Steal ni sifa ya virtual machine, si ya container inayokimbia ndani yake. Docker container kwenye VPS yako inashiriki /proc ya mwenyeji, kwa hivyo thamani ya st inayosomwa ndani yake ni steal ya VPS, ambayo ndiyo unayotaka. Virtualisation inayotegemea container inayouzwa kama VPS hufanya kazi kwa njia tofauti. Pamoja na lxcfs, /proc/stat ndani ya container hutengenezwa kutokana na uhasibu wa cgroup, na steal huwa sifuri kwa usanifu wake. Mfumo wa ufuatiliaji unaokusanya data kutoka ndani pekee unaweza kuonyesha sifuri iliyotulia wakati mashine ya kimwili iliyo chini yake inakosa rasilimali.

Ndani ya container, kipingi chenye maana sawa ni CPU quota throttling. Kwenye cgroup v2:

cat /sys/fs/cgroup/cpu.stat

nr_throttled huhesabu vipindi vya utekelezaji ambavyo kundi lilifikia kikomo chake cha CPU, na throttled_usec hupiga jumla ya muda uliotumika ukiwa umesitishwa. nr_throttled inayopanda inamaanisha mchakato wako ulikuwa tayari kukimbia lakini haukukimbia, hali inayofanana na steal, lakini inayosababishwa na kikomo ulichojiwekea mwenyewe. Angalia vikomo vyako kabla ya kuilaumu seva mwenyeji, hasa ikiwa unatumia huduma zako kwenye Docker ndani ya VPS yenye vikomo vya CPU kwenye faili ya compose. Virtualisation ya matabaka huongeza sehemu nyingine ambapo muda unaweza kupotea, kwa sababu VM iliyo ndani ya VPS yako hulipa steal yako pamoja na ucheleweshaji wake wa kupanga ratiba. Kumbuka hili ikiwa unatumia nested virtualisation kwenye VPS.

Nini cha kufanya kuhusu steal inayoendelea

Hakuna mpangilio wowote ndani ya guest unaoweza kurekebisha steal, kwa sababu scheduler inayofanya uamuzi huo inaendeshwa nje ya guest. Kuboresha kernel hakubadilishi hali hiyo pia: cache aware scheduling iliyoongezwa kwenye Linux kernel 7.2 hupanga upya kazi zako kwenye cores ulizopewa, na haiwezi kurejesha mizunguko (cycles) ambayo jirani tayari ameichukua. Kuna hatua nne za kweli.

Kusanya ushahidi kwanza. Rekodi nyakati katika UTC, muda wa kila tukio, marudio yake, na kama mpstat inaonyesha vCPU moja imeathirika au zote. Wiki moja ya sampuli zilizorekodiwa ina thamani zaidi kuliko picha ya skrini (screenshot).

Fungua tiketi ukiwa na data hizo. Uliza maswali mawili ya moja kwa moja: je, node hii imezidiwa (oversubscribed) wakati wa vipindi hivi, na je, instance yangu inaweza kuhamishwa. Bandika matokeo ya vmstat na nyakati kamili. Watoa huduma huchukua hatua pale wanapoona kipindi kinachoweza kurudiwa, na tiketi inayosema tu kuwa seva ni ya polepole hupata jibu la kuomba data hizo. Kiasi cha kazi unachoweza kukabidhi kwa mtoa huduma ni moja ya tofauti za kiutendaji kati ya VPS inayodhibitiwa na isiyodhibitiwa.

Omba uhamisho (migration). Kuhamisha guest kwenda kwenye node isiyo na mzigo mkubwa ni kazi ya kawaida kwa mtoa huduma, na kwa kawaida ni reboot fupi tu. Hii ndiyo suluhisho lisilogharimu chochote, na hutatua hali ya kawaida, ambapo node moja hutokea kuwa na majirani kadhaa wenye mzigo mkubwa kwa wakati mmoja.

Ondoa contention kwa kununua rasilimali. Mpango wa dedicated vCPU hutenga cores za kimwili kwa ajili ya instance yako, hivyo counter hubaki kwenye sifuri na kubaki hapo. Inagharimu zaidi kila mwezi, na ndiyo jibu la kweli kwa workload isiyoweza kuhimili mabadiliko ya kasi. Ikiwa hiyo bado haitoshi, au unataka memory bandwidth iwe yako pekee, hatua inayofuata ni seva ya kujitolea (dedicated server) badala ya VPS.

Unaposubiri yoyote ya hayo, punguza kiasi ambacho steal inakuathiri. Endesha worker threads chache kuliko idadi ya vCPUs ulizonazo, kwa sababu threads zisizoweza kupata core huongeza tu context switches. Hamishia kazi za batch kwenye saa ambazo node iko tulivu, jambo ambalo log yako sasa inakuambia. Kisha pima tena kwa kutumia amri ileile katika saa zilezile, ili uweze kusema kama mabadiliko yamefanya kazi badala ya kukisia.

FAQ

Je, ni kiasi gani cha kawaida cha CPU steal time kwenye VPS?

Kwenye mpango wa rasilimali zilizoshirikiwa (shared plan), ongezeko la muda mfupi na thamani ya kudumu chini ya asilimia 5 ni ya kawaida, kwa sababu CPU iliyoshirikiwa inamaanisha mwenyeji (host) hugawa cores za kimwili kati ya wageni (guests). Thamani ya tarakimu mbili inayodumu kwa saa nyingi si ya kawaida na inastahili tiketi ya msaada. Kwenye mpango wa vCPU iliyojitolea (dedicated vCPU), usomaji unaotarajiwa ni 0.0, kwa hivyo thamani nyingine yoyote hapo ni hitilafu inayopaswa kuripotiwa. Tathmini namba hiyo kulingana na mzigo wako wa kazi: kazi ya kundi (batch job) ya usiku inaweza kuvumilia steal ambayo API inayohitaji mwitikio wa haraka haiwezi.

Je, mpango mkubwa zaidi utatatua steal time ya juu?

Si peke yake. vCPUs zaidi kwenye node ileile iliyoshirikiwa inamaanisha vCPUs nyingi zaidi zinashindania cores zilezile za kimwili zenye msongamano, na asilimia inaweza kubaki pale ilipokuwa. Kinachoondoa steal ni mgao wa CPU uliotengwa (dedicated CPU allocation), au kuhamia kwenye node isiyo na mzigo mkubwa. Sehemu kubwa ya mashine yenye shughuli nyingi bado ni sehemu ya mashine yenye shughuli nyingi.

Kwa nini VPS yangu inaonyesha 0 steal time wakati ni polepole dhahiri?

Kuna sababu mbili za kawaida. Hypervisor inaweza isionyeshe kaunta hiyo kabisa, jambo ambalo ni la kawaida kwenye majukwaa ya VMware na Hyper-V, kwa hivyo uwanja huo unabaki kwenye sifuri bila kujali mwenyeji anafanya nini. Endesha systemd-detect-virt ili kuona ni jukwaa gani unalotumia. Vinginevyo, kizuizi kiko mahali pengine: angalia wa kwa ajili ya kusubiri hifadhi (storage waits), linganisha r na nproc kwa ajili ya mzigo wako mwenyewe, na usome /sys/fs/cgroup/cpu.stat ndani ya containers kwa ajili ya kupunguzwa kwa quota (throttling).

Je, ninaweza kupunguza steal time kutoka ndani ya seva yangu?

Huwezi kubadilisha ratiba ya mwenyeji (host's scheduling) ukiwa ndani ya mgeni (guest). Unaweza tu kupunguza kiasi kinachokuumiza. Endesha thread chache za kazi kuliko idadi ya vCPUs ulizonazo, ili kazi kidogo ikae kwenye foleni ya utekelezaji ikisubiri core ambayo haiji. Hamisha kazi za kundi (batch jobs) kwenye saa ambazo node imetulia zaidi. Hifadhi matokeo (cache) ili maombi machache yahitaji CPU kabisa. Mabadiliko yanayoondoa steal kweli, kama kuhama kwenda node nyingine au kutumia cores zilizojitolea, yako upande wa mtoa huduma.