CPU steal time ni nini kwenye VPS?

Kile ambacho CPU steal time hupima kihalisi

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 (guest) mwingine. Kazi hiyo ilikuwa kwenye foleni. Core ilikuwa mahali pengine. Linux huhesabu mizunguko hiyo kando na kuiripoti kama st, ambayo ndiyo njia unayotumia kutofautisha "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 na hifadhi huripotiwa kama wa (I/O wait). vCPU (virtual CPU) ambayo inaweza kufanya kazi, ikiwa 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 inafuata moja kwa moja kutoka kwa 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 hugawa cores kati yako na yeye. Kuna sababu ya pili ambayo mara nyingi hupuuzwa. Watoa huduma wengi huweka kikomo cha vCPU iliyoshirikiwa kwa sehemu ya core ya kimwili, na kwenye hypervisors kadhaa, kikomo hicho kilichotekelezwa huhesabiwa kama steal ndani ya guest. 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 kwa CONFIG_PARAVIRT_TIME_ACCOUNTING, jambo ambalo kila kernel ya distribution hufanya. 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 yeyote Prometheus exporter, husoma sehemu hiyo hiyo na kubadilisha 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 iliyojengwa juu yake huripoti 0.0 tulivu wakati host imezidiwa. KVM na Xen huitoa. Guests kwenye VMware na Hyper-V mara nyingi huripoti sifuri kamili. Kagua platform kabla ya kuamini sifuri:

systemd-detect-virt

Huchapisha jina la platform, kama vile kvm, xen, vmware au microsoft, na none kwenye bare metal. Ndani ya container huripoti runtime badala yake, kama vile lxc, docker au podman, ambayo hukuambia 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 kamwe, sifuri si ushahidi wowote, na contention lazima ihukumiwe kwa kupima muda wa kazi halisi badala yake.

Jinsi ya kukagua CPU steal time kwenye VPS?

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

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 utachapishwa, zana hiyo imesakinishwa na unasoma vihesabio 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 iko ya pili kutoka kulia badala ya kuwa ya mwisho. Soma safu hiyo kwa jina la kichwa chake, kwa sababu nafasi hiyo imebadilika kati ya matoleo.

Tabia mbili huweka usahihi wa usomaji. Mstari wa kwanza wa data ni wastani tangu kuanza kwa mfumo (boot), kwa hivyo uupuuze na usome mistari inayofuata. Na sampuli moja si kipimo, kwa sababu steal hufika kwa vipindi: endesha vmstat 1 60 na ufuatilie kwa dakika nzima kabla ya kufikia hitimisho.

top huripoti namba hiyo hiyo kwenye mstari wake wa muhtasari wa %Cpu(s), katika sehemu iliyotiwa alama ya 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 na safu ya %steal, ambayo inaonyesha kama kila vCPU imeathirika au moja tu. Kwa ajili ya historia inayohitajika na tiketi ya usaidizi, hifadhi sampuli 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.

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 unaodumu kwa sekunde. Hali ya kawaida kwenye node yoyote inayoshirikiwa. Kazi ya jirani inaanza, au mwenyeji anaendesha backups zake.
• Asilimia 1 hadi 5 zinazoendelea kwenye mpango wa pamoja. Inatarajiwa. CPU inayoshirikiwa ndiyo inayozingatiwa kwenye bei.
• Asilimia 5 hadi 10 zinazoendelea. Kupungua kwa kasi unakoweza 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 tiketi ya msaada au kuhama.

Chukulia viwango hivyo kama mwongozo wa usomaji badala ya vipimo rasmi, kwa sababu hakuna mtoa huduma anayechapisha dhamana ya steal kwenye mpango wa pamoja. Vipime kulingana na kile unachoendesha. Kazi ya batch ya usiku inaweza kuvumilia asilimia 15 ya steal na hakuna anayeona. Huduma inayohisi latency huonyesha hilo kwenye p99 muda mrefu kabla ya wastani kuonekana kuwa wa kutisha, ndiyo maana mzigo wa kazi unaohisi latency kama roboti 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 unachukulia kuwa kuna thread moja inayoweza kufanya kazi na steal inasambazwa sawasawa katika kipindi hicho. Huduma halisi mara nyingi huhisi mbaya zaidi kuliko mkondo huo, kwa sababu kipande kilichoibiwa hutokea katikati ya ombi na ucheleweshaji huo hulipiwa tena na kila kitu kinachosubiri ombi hilo. Ili kupata takwimu yako 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 mmoja wa vmstat.

• st iko juu wakati r na us zikiwa chini: seva pangishi (host) haikupi core. Hiyo ndiyo steal.
• r iko juu zaidi ya idadi yako ya vCPU, 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, si jirani.
• 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 iliyopoteza muunganisho badala ya tatizo la CPU.

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

Kwa nini container haionyeshi steal time

Steal ni sifa ya virtual machine, si ya container inayofanya kazi ndani yake. Docker container kwenye VPS yako inashiriki /proc ya mwenyeji, kwa hivyo thamani ya st inayosomwa ndani yake ni steal ya VPS yenyewe, jambo ambalo ndilo unalotaka. Virtualisation inayotegemea container inayouzwa kama VPS hufanya kazi kwa njia tofauti. Pamoja na lxcfs, /proc/stat ndani ya container hutengenezwa kutoka kwa 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 inakosa rasilimali.

Ndani ya container, kaunta yenye maana sawa ni CPU quota throttling. Kwenye cgroup v2:

cat /sys/fs/cgroup/cpu.stat

nr_throttled huhesabu vipindi vya utekelezaji ambapo kundi lilifikia kikomo chake cha CPU, na throttled_usec hu jumlisha muda uliotumika ukiwa umesitishwa. nr_throttled inayopanda inamaanisha mchakato wako ulikuwa tayari kufanya kazi lakini haukuwa unafanya kazi, hali inayofanana na steal, lakini inayosababishwa na kikomo ulichojiwekea mwenyewe. Kagua vikomo vyako kabla ya kulaumu mwenyeji, hasa ikiwa unaendesha huduma zako kwenye Docker ndani ya VPS na 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 kuratibu. Zingatia hili ikiwa unaendesha 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. 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 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 kwenye vipindi vinavyoweza kurudiwa, na tiketi inayosema tu kuwa seva ni ya polepole hupata jibu la kuomba data hizo. Kiasi gani cha kazi hii 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 bandwidth ya kumbukumbu peke yako pia, hatua inayofuata ni seva ya kujitolea (dedicated server) badala ya VPS.

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

FAQ

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

Kwenye mpango wa shared, ongezeko la muda mfupi na thamani endelevu ya chini ya asilimia 5 ni ya kawaida, kwa sababu CPU ya shared inamaanisha kuwa mwenyeji (host) hugawanya cores za kimwili kati ya wageni (guests). Thamani endelevu ya tarakimu mbili kwa saa nyingi si ya kawaida na inastahili tiketi ya msaada. Kwenye mpango wa dedicated vCPU, thamani inayotarajiwa ni 0.0, kwa hivyo chochote kingine hapo ni hitilafu inayopaswa kuripotiwa. Tathmini namba hiyo kulingana na mzigo wako wa kazi: kazi ya batch ya usiku inaweza kuvumilia steal ambayo API inayohitaji latency ndogo haiwezi.

Je, mpango mkubwa zaidi utatatua steal time ya juu?

Si peke yake. vCPUs zaidi kwenye node ileile ya shared inamaanisha vCPU nyingi zaidi zinashindania cores zilezile za kimwili zenye msongamano, na asilimia inaweza kubaki pale ilipokuwa. Kinachoondoa steal ni ugawaji wa CPU ya dedicated, 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?

Kuna sababu mbili za kawaida. Hypervisor inaweza isionyeshe counter hiyo kabisa, jambo ambalo ni la kawaida kwenye majukwaa ya VMware na Hyper-V, kwa hivyo sehemu hiyo inabaki 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 overload yako mwenyewe, na usome /sys/fs/cgroup/cpu.stat ndani ya containers kwa ajili ya quota throttling.

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

Huwezi kubadilisha ratiba ya mwenyeji ukiwa ndani ya mgeni. Unaweza tu kupunguza kiasi ambacho kinakuathiri. Endesha worker threads chache kuliko idadi ya vCPUs ulizonazo, ili kazi kidogo ikae kwenye run queue ikisubiri core ambayo haiji. Hamisha kazi za batch kwenye saa ambazo node haina shughuli nyingi. Hifadhi matokeo (cache) ili maombi machache yahitaji CPU kabisa. Mabadiliko ambayo huondoa steal kweli, kama kuhama kwenda kwenye node nyingine au kutumia dedicated cores, yako upande wa mtoa huduma.