Ukisimamia miundombinu pepe kulingana na VMware vSphere (au rundo lolote la teknolojia), huenda mara nyingi husikia malalamiko kutoka kwa watumiaji: "Mashine pepe iko polepole!" Katika mfululizo huu wa makala nitachambua metrics ya utendaji na kukuambia nini na kwa nini inapungua na jinsi ya kuhakikisha kuwa haipunguzi.
Nitazingatia vipengele vifuatavyo vya utendaji wa mashine halisi:
- CPU,
- RAM,
- DISK,
- Mtandao.
Nitaanza na CPU.
Ili kuchambua utendaji tutahitaji:
- Vihesabu vya Utendaji vya vCenter - vihesabio vya utendaji, grafu ambazo zinaweza kutazamwa kupitia Mteja wa vSphere. Taarifa kwenye vihesabio hivi inapatikana katika toleo lolote la mteja (teja "nene" katika C#, mteja wa wavuti katika Flex na mteja wa wavuti katika HTML5). Katika nakala hizi tutatumia picha za skrini kutoka kwa mteja wa C #, kwa sababu tu zinaonekana bora katika miniature :)
- ESXTOP - matumizi ambayo huendesha kutoka kwa safu ya amri ya ESXi. Kwa usaidizi wake, unaweza kupata thamani za vihesabio vya utendakazi kwa wakati halisi au upakie thamani hizi kwa muda fulani kwenye faili ya .csv kwa uchanganuzi zaidi. Ifuatayo, nitakuambia zaidi kuhusu chombo hiki na kutoa viungo kadhaa muhimu kwa nyaraka na makala juu ya mada.
Nadharia kidogo
Katika ESXi, mchakato tofauti - ulimwengu katika istilahi za VMware - unawajibika kwa utendakazi wa kila vCPU (msingi wa mashine halisi). Pia kuna michakato ya huduma, lakini kutoka kwa mtazamo wa kuchambua utendaji wa VM wao ni chini ya kuvutia.
Mchakato katika ESXi unaweza kuwa katika mojawapo ya majimbo manne:
- Kukimbia - mchakato hufanya kazi fulani muhimu.
- Kusubiri - mchakato haufanyi kazi yoyote (bila kufanya kazi) au unangojea pembejeo / pato.
- Gharama - hali ambayo hutokea katika mashine nyingi za msingi za mtandaoni. Hutokea wakati kipanga ratiba cha hypervisor CPU (ESXi CPU Scheduler) hakiwezi kuratibu utekelezaji wa wakati mmoja wa viini vyote amilifu vya mashine kwenye viini vya seva halisi. Katika ulimwengu wa kimwili, cores zote za processor hufanya kazi kwa sambamba, OS mgeni ndani ya VM anatarajia tabia sawa, kwa hivyo hypervisor inapaswa kupunguza kasi ya cores za VM ambazo zina uwezo wa kumaliza mzunguko wao wa saa kwa kasi zaidi. Katika matoleo ya kisasa ya ESXi, kipanga ratiba cha CPU hutumia utaratibu unaoitwa uratibu wa pamoja uliolegea: kiboreshaji kinazingatia pengo kati ya msingi wa mashine "wenye kasi zaidi" na msingi "polepole zaidi" wa mashine (skew). Ikiwa pengo linazidi kizingiti fulani, msingi wa haraka huingia katika hali ya gharama. Ikiwa cores za VM hutumia muda mwingi katika hali hii, inaweza kusababisha masuala ya utendaji.
- Tayari - mchakato huingia katika hali hii wakati hypervisor haiwezi kutenga rasilimali kwa ajili ya utekelezaji wake. Thamani za juu zilizo tayari zinaweza kusababisha shida za utendaji wa VM.
Kaunta za msingi za utendaji za CPU za mashine pepe
Matumizi ya CPU,%. Inaonyesha asilimia ya matumizi ya CPU kwa kipindi fulani.
Jinsi ya kuchambua? Ikiwa VM hutumia CPU kila mara kwa 90% au kuna kilele hadi 100%, basi tuna shida. Shida zinaweza kuonyeshwa sio tu katika operesheni ya "polepole" ya programu ndani ya VM, lakini pia katika kutoweza kufikiwa kwa VM kwenye mtandao. Ikiwa mfumo wa ufuatiliaji unaonyesha kuwa VM huanguka mara kwa mara, zingatia kilele katika grafu ya Matumizi ya CPU.
Kuna Kengele ya kawaida inayoonyesha mzigo wa CPU wa mashine ya kawaida:
Nini cha kufanya? Ikiwa Matumizi ya CPU ya VM yanapitia paa kila wakati, basi unaweza kufikiria juu ya kuongeza idadi ya vCPU (kwa bahati mbaya, hii haisaidii kila wakati) au kuhamisha VM kwa seva iliyo na wasindikaji wenye nguvu zaidi.
Matumizi ya CPU katika MHz
Katika grafu kwenye Matumizi ya vCenter katika % unaweza kuona tu kwa mashine nzima ya mtandaoni; hakuna grafu za cores binafsi (katika Esxtop kuna % thamani za cores). Kwa kila msingi unaweza kuona Matumizi katika MHz.
Jinsi ya kuchambua? Inatokea kwamba programu haijaboreshwa kwa usanifu wa msingi-nyingi: hutumia msingi mmoja tu 100%, na iliyobaki haina kazi bila mzigo. Kwa mfano, kwa mipangilio chaguo-msingi ya chelezo, MS SQL huanza mchakato kwenye msingi mmoja tu. Matokeo yake, uhifadhi hupungua si kwa sababu ya kasi ya polepole ya disks (hii ndiyo ambayo mtumiaji alilalamika hapo awali), lakini kwa sababu processor haiwezi kukabiliana. Tatizo lilitatuliwa kwa kubadilisha vigezo: Backup ilianza kukimbia sambamba katika faili kadhaa (kwa mtiririko huo, katika michakato kadhaa).
Mfano wa mzigo usio na usawa kwenye cores.
Pia kuna hali (kama kwenye grafu hapo juu) wakati cores zinapakiwa bila usawa na baadhi yao wana kilele cha 100%. Kama ilivyo kwa kupakia msingi mmoja tu, kengele ya Matumizi ya CPU haitafanya kazi (ni kwa VM nzima), lakini kutakuwa na shida za utendaji.
Nini cha kufanya? Ikiwa programu katika mashine ya kawaida hupakia cores bila usawa (hutumia msingi mmoja tu au sehemu ya cores), hakuna maana katika kuongeza idadi yao. Katika kesi hii, ni bora kuhamisha VM kwa seva iliyo na wasindikaji wenye nguvu zaidi.
Unaweza pia kujaribu kuangalia mipangilio ya matumizi ya nguvu katika BIOS ya seva. Wasimamizi wengi huwezesha hali ya Utendaji wa Juu katika BIOS na hivyo kuzima teknolojia za kuokoa nishati za majimbo ya C na P-states. Wasindikaji wa kisasa wa Intel hutumia teknolojia ya Turbo Boost, ambayo huongeza mzunguko wa cores ya mtu binafsi kwa gharama ya cores nyingine. Lakini inafanya kazi tu wakati teknolojia za kuokoa nishati zimewashwa. Ikiwa tutazizima, processor haiwezi kupunguza matumizi ya nguvu ya cores ambayo haijapakiwa.
VMware inapendekeza sio kuzima teknolojia za kuokoa nguvu kwenye seva, lakini uchague njia zinazoacha usimamizi wa nguvu kwa hypervisor iwezekanavyo. Katika kesi hii, katika mipangilio ya matumizi ya nguvu ya hypervisor, unahitaji kuchagua Utendaji wa Juu.
Iwapo una VM binafsi (au viini vya VM) katika miundombinu yako inayohitaji kuongezeka kwa mzunguko wa CPU, kurekebisha kwa usahihi matumizi ya nishati kunaweza kuboresha utendaji wao kwa kiasi kikubwa.
CPU Tayari
Ikiwa msingi wa VM (vCPU) uko katika hali ya Tayari, haifanyi kazi muhimu. Hali hii hutokea wakati hypervisor haipati msingi wa kimwili wa bure ambao mchakato wa vCPU wa mashine ya kawaida unaweza kupewa.
Jinsi ya kuchambua? Kwa kawaida, kama viini vya mashine pepe viko katika hali ya Tayari zaidi ya 10% ya wakati, utaona matatizo ya utendaji. Kwa ufupi, zaidi ya 10% ya muda ambao VM inasubiri rasilimali za kimwili kupatikana.
Katika vCenter unaweza kuona vihesabio 2 vinavyohusiana na Tayari kwa CPU:
- utayari,
- Tayari.
Thamani za hesabu zote mbili zinaweza kutazamwa kwa VM nzima na kwa alama za kibinafsi.
Utayari huonyesha thamani mara moja kama asilimia, lakini katika Wakati Halisi pekee (data ya saa iliyopita, muda wa kipimo cha sekunde 20). Ni bora kutumia counter hii tu kutafuta shida "moto kwenye visigino".
Thamani zilizo tayari za kukabiliana zinaweza kutazamwa kutoka kwa mtazamo wa kihistoria. Hii ni muhimu kwa kuanzisha mifumo na kwa uchambuzi wa kina wa shida. Kwa mfano, ikiwa mashine pepe itaanza kupata matatizo ya utendaji kwa wakati fulani, unaweza kulinganisha vipindi vya thamani ya Tayari ya CPU na jumla ya mzigo kwenye seva ambapo VM hii inafanya kazi, na kuchukua hatua za kupunguza mzigo (ikiwa DRS inashindwa).
Tayari, tofauti na Utayari, hauonyeshwa kwa asilimia, lakini kwa milliseconds. Hii ni kihesabu cha aina ya Muhtasari, yaani, inaonyesha muda gani wakati wa kipimo msingi wa VM ulikuwa katika hali ya Tayari. Unaweza kubadilisha thamani hii kuwa asilimia kwa kutumia fomula rahisi:
(CPU tayari thamani ya muhtasari / (muda wa kusasisha chati katika sekunde * 1000) * 100 = CPU tayari%
Kwa mfano, kwa VM kwenye jedwali hapa chini, bei ya kilele Tayari kwa mashine nzima ya mtandaoni itakuwa kama ifuatavyo.
Wakati wa kuhesabu asilimia Tayari, unapaswa kuzingatia pointi mbili:
- Thamani iliyo Tayari kwa VM nzima ni jumla ya Tayari kwa alama zote.
- Muda wa kipimo. Kwa muda halisi ni sekunde 20, na, kwa mfano, kwenye chati za kila siku ni sekunde 300.
Kwa utatuzi amilifu, vidokezo hivi rahisi vinaweza kukosekana kwa urahisi na wakati wa thamani unaweza kupotea katika kutatua shida ambazo hazipo.
Wacha tuhesabu Tayari kulingana na data kutoka kwa grafu hapa chini. (324474/(20*1000))*100 = 1622% kwa VM nzima. Ukiangalia cores sio ya kutisha sana: 1622/64 = 25% kwa kila msingi. Katika kesi hii, kukamata ni rahisi sana kuona: Thamani ya Tayari sio ya kweli. Lakini ikiwa tunazungumzia kuhusu 10-20% kwa VM nzima na cores kadhaa, basi kwa kila msingi thamani inaweza kuwa ndani ya aina ya kawaida.
Nini cha kufanya? Thamani ya juu iliyo Tayari inaonyesha kuwa seva haina rasilimali za kutosha za kichakataji kwa utendakazi wa kawaida wa mashine pepe. Katika hali kama hii, kinachobakia ni kupunguza usajili zaidi na processor (vCPU:pCPU). Ni wazi, hii inaweza kupatikana kwa kupunguza vigezo vya VM zilizopo au kwa kuhamisha sehemu ya VM hadi seva zingine.
Co-stop
Jinsi ya kuchambua? Kaunta hii pia ni ya aina ya Muhtasari na inabadilishwa kuwa asilimia kwa njia sawa na Tayari:
(Thamani ya kusimamisha ushirikiano kwa CPU / (muda wa kusasisha chati chaguo-msingi katika sekunde * 1000)) * 100 = CPU co-stop%
Hapa unahitaji pia kuzingatia idadi ya cores kwenye VM na muda wa kipimo.
Katika hali ya gharama kubwa, kernel haifanyi kazi muhimu. Kwa uteuzi sahihi wa ukubwa wa VM na mzigo wa kawaida kwenye seva, counter-stop counter inapaswa kuwa karibu na sifuri.
Katika kesi hii, mzigo ni wazi usio wa kawaida :)
Nini cha kufanya? Ikiwa VM kadhaa zilizo na idadi kubwa ya cores zinaendesha kwenye hypervisor moja na kuna usajili wa ziada kwenye CPU, basi counter-stop counter inaweza kuongezeka, ambayo itasababisha matatizo na utendaji wa VM hizi.
Pia, kuacha pamoja kutaongezeka ikiwa viini amilifu vya VM moja vitatumia nyuzi kwenye msingi mmoja wa seva huku kukanyaga kwa kasi kukiwashwa. Hali hii inaweza kutokea, kwa mfano, ikiwa VM ina cores nyingi kuliko zinazopatikana kwenye seva ambapo inaendeshwa, au ikiwa mpangilio wa "preferHT" umewashwa kwa VM. Unaweza kusoma kuhusu mpangilio huu .
Ili kuepuka matatizo na utendakazi wa VM kutokana na usimamaji wa juu wa ushirikiano, chagua ukubwa wa VM kwa mujibu wa mapendekezo ya mtengenezaji wa programu inayoendeshwa kwenye VM hii na uwezo wa seva halisi ambapo VM inaendeshwa.
Usiongeze cores kwenye hifadhi; hii inaweza kusababisha matatizo ya utendaji sio tu kwa VM yenyewe, lakini pia kwa majirani zake kwenye seva.
Vipimo vingine muhimu vya CPU
Kukimbia - ni muda gani (ms) wakati wa kipindi cha kipimo vCPU ilikuwa katika hali ya RUN, yaani, ilikuwa ikifanya kazi muhimu.
Uvivu - muda gani (ms) katika kipindi cha kipimo vCPU ilikuwa katika hali ya kutofanya kazi. Maadili ya hali ya juu sio shida, vCPU haikuwa na "chochote cha kufanya."
Kusubiri - muda gani (ms) katika kipindi cha kipimo vCPU ilikuwa katika hali ya Kusubiri. Kwa kuwa IDLE imejumuishwa kwenye kaunta hii, viwango vya juu vya Kusubiri pia havionyeshi tatizo. Lakini ikiwa Wait IDLE iko chini wakati Wait iko juu, inamaanisha kuwa VM ilikuwa ikingojea shughuli za I/O zikamilike, na hii, kwa upande wake, inaweza kuonyesha shida na utendakazi wa diski kuu au vifaa vyovyote vya kawaida vya VM.
Upeo mdogo - muda gani (ms) katika kipindi cha kipimo vCPU ilikuwa katika hali ya Tayari kutokana na kikomo cha rasilimali kilichowekwa. Ikiwa utendakazi ni wa chini kwa njia isiyoelezeka, basi ni muhimu kuangalia thamani ya kihesabu hiki na kikomo cha CPU katika mipangilio ya VM. VM zinaweza kuwa na mipaka ambayo hujui. Kwa mfano, hii hutokea wakati VM iliundwa kutoka kwa kiolezo ambacho kikomo cha CPU kiliwekwa.
Badili subiri - muda gani katika kipindi cha kipimo vCPU ilisubiri operesheni na Ubadilishanaji wa VMkernel. Ikiwa maadili ya counter hii ni juu ya sifuri, basi VM hakika ina matatizo ya utendaji. Tutazungumza zaidi kuhusu SWAP katika makala kuhusu vihesabu vya RAM.
ESXTOP
Ikiwa vihesabu vya utendakazi katika vCenter ni vyema kwa kuchanganua data ya kihistoria, basi uchanganuzi wa uendeshaji wa tatizo unafanywa vyema katika ESXTOP. Hapa, maadili yote yanawasilishwa kwa fomu iliyotengenezwa tayari (hakuna haja ya kutafsiri chochote), na kipindi cha chini cha kipimo ni sekunde 2.
Skrini ya ESXTOP ya CPU inaitwa na kitufe cha "c" na inaonekana kama hii:
Kwa urahisi, unaweza kuacha michakato ya mashine tu kwa kubonyeza Shift-V.
Ili kuona vipimo vya alama za VM mahususi, bonyeza βeβ na uweke GID ya VM inayokuvutia (30919 katika picha ya skrini iliyo hapa chini):
Acha nipitie kwa ufupi safuwima ambazo zinawasilishwa kwa chaguo-msingi. Safu wima za ziada zinaweza kuongezwa kwa kubonyeza "f".
NWLD (Idadi ya Walimwengu) - idadi ya michakato katika kikundi. Ili kupanua kikundi na kuona vipimo vya kila mchakato (kwa mfano, kwa kila msingi katika VM ya msingi nyingi), bonyeza "e". Ikiwa kuna mchakato zaidi ya mmoja katika kikundi, basi thamani za metri za kikundi ni sawa na jumla ya vipimo vya michakato ya mtu binafsi.
%USED - ni mizunguko ngapi ya seva ya CPU hutumiwa na mchakato au kikundi cha michakato.
%RUN - muda gani wakati wa kipindi cha kipimo mchakato ulikuwa katika hali ya RUN, i.e. ilifanya kazi yenye manufaa. Inatofautiana na %USED kwa kuwa haizingatii upigaji nyuzi nyingi, kuongeza kasi na muda unaotumika kwenye kazi za mfumo (%SYS).
%SYS β muda unaotumika kwenye kazi za mfumo, kwa mfano: kukatiza usindikaji, I/O, uendeshaji wa mtandao, n.k. Thamani inaweza kuwa ya juu ikiwa VM ina I/O kubwa.
%OVRLP - muda gani msingi wa kimwili ambao mchakato wa VM unaendelea ulitumia kwa kazi za michakato mingine.
Vipimo hivi vinahusiana kama ifuatavyo:
%USED = %RUN + %SYS - %OVRLP.
Kwa kawaida kipimo cha %USED kina taarifa zaidi.
SUBIRI - muda gani katika kipindi cha kipimo mchakato ulikuwa katika hali ya Kusubiri. Inawasha IDLE.
%BILA KAZI - muda gani katika kipindi cha kipimo mchakato ulikuwa katika hali ya IDLE.
%SWWPWT - muda gani katika kipindi cha kipimo vCPU ilisubiri operesheni na Ubadilishanaji wa VMkernel.
%VMWAIT - muda gani katika kipindi cha kipimo vCPU ilikuwa katika hali ya kusubiri tukio (kawaida I/O). Hakuna kihesabu sawa katika vCenter. Thamani za juu zinaonyesha shida na I/O kwenye VM.
%SUBIRI = %VMWAIT + %IDLE + %SWPWT.
Ikiwa VM haitumii Ubadilishanaji wa VMkernel, basi wakati wa kuchambua shida za utendaji inashauriwa kuangalia %VMWAIT, kwani metriki hii haizingatii wakati ambapo VM haikufanya chochote (%IDLE).
%RDY - muda gani katika kipindi cha kipimo mchakato ulikuwa katika hali Tayari.
%CSTP - muda gani katika kipindi cha kipimo mchakato ulikuwa katika hali ya gharama.
%MLMTD - muda gani katika kipindi cha kipimo vCPU ilikuwa katika hali ya Tayari kutokana na kikomo cha rasilimali kilichowekwa.
%SUBIRI + %RDY + %CSTP + %RUN = 100% - msingi wa VM huwa katika mojawapo ya majimbo haya manne.
CPU kwenye hypervisor
vCenter pia ina vihesabio vya utendaji vya CPU kwa hypervisor, lakini hazifurahishi - ni jumla ya vihesabio vya VM zote kwenye seva.
Njia rahisi zaidi ya kutazama hali ya CPU kwenye seva iko kwenye kichupo cha Muhtasari:
Kwa seva, na vile vile kwa mashine ya kawaida, kuna Kengele ya kawaida:
Wakati mzigo wa CPU wa seva unapokuwa juu, VM zinazoendesha juu yake huanza kupata matatizo ya utendaji.
Katika ESXTOP, data ya upakiaji wa seva ya CPU inawasilishwa juu ya skrini. Kwa kuongeza mzigo wa kawaida wa CPU, ambayo sio habari sana kwa hypervisors, kuna metriki tatu zaidi:
CORE UTIL(%) - kupakia kiini cha seva halisi. Kaunta hii inaonyesha muda ambao msingi ulifanya kazi katika kipindi cha kipimo.
PCPU UTIL(%) - ikiwa uwekaji nyuzi nyingi umewezeshwa, basi kuna nyuzi mbili (PCPU) kwa kila msingi wa kimwili. Kipimo hiki kinaonyesha muda ambao kila uzi ulichukua kukamilisha kazi.
PCPU ILIYOTUMIKA(%) - sawa na PCPU UTIL(%), lakini inazingatia kuongeza masafa (ama kupunguza masafa ya msingi kwa madhumuni ya kuokoa nishati, au kuongeza masafa ya msingi kwa sababu ya teknolojia ya Turbo Boost) na utaftaji mwingi.
PCPU_USED% = PCPU_UTIL% * masafa ya msingi bora / masafa ya msingi ya kawaida.
Katika picha hii ya skrini, kwa baadhi ya cores, kutokana na Turbo Boost, thamani ya USED ni kubwa kuliko 100%, kwa kuwa mzunguko wa msingi ni wa juu kuliko moja ya kawaida.
Maneno machache kuhusu jinsi hyper-threading inazingatiwa. Ikiwa michakato itatekelezwa 100% ya muda kwenye nyuzi zote mbili za msingi halisi wa seva, wakati msingi unafanya kazi kwa mzunguko wa kawaida, basi:
- CORE UTIL kwa msingi itakuwa 100%,
- PCPU UTIL kwa nyuzi zote mbili itakuwa 100%,
- PCPU ILIYOTUMIKA kwa nyuzi zote mbili itakuwa 50%.
Ikiwa nyuzi zote mbili hazikufanya kazi 100% ya muda wakati wa kipimo, basi katika vipindi hivyo wakati nyuzi zilifanya kazi sambamba, PCPU USED kwa cores imegawanywa kwa nusu.
ESXTOP pia ina skrini iliyo na vigezo vya matumizi ya nguvu ya seva ya CPU. Hapa unaweza kuona kama seva inatumia teknolojia za kuokoa nishati: C-states na P-states. Inaitwa na kitufe cha "p":
Masuala ya Utendaji ya CPU ya Kawaida
Hatimaye, nitapitia sababu za kawaida za matatizo na utendaji wa VM CPU na kutoa vidokezo vifupi vya kuzitatua:
Kasi ya saa ya msingi haitoshi. Ikiwa haiwezekani kusasisha VM yako hadi viini vyenye nguvu zaidi, unaweza kujaribu kubadilisha mipangilio ya nguvu ili kufanya Turbo Boost ifanye kazi kwa ufanisi zaidi.
Saizi ya VM isiyo sahihi (cores nyingi sana/chache). Ikiwa utasanikisha cores chache, kutakuwa na mzigo mkubwa wa CPU kwenye VM. Ikiwa kuna mengi, pata ushirikiano wa juu.
Usajili mkubwa wa CPU kwenye seva. Ikiwa VM ina Tayari ya juu, punguza usajili wa ziada wa CPU.
Topolojia ya NUMA kwenye VM kubwa si sahihi. Topolojia ya NUMA inayoonekana na VM (vNUMA) lazima ilingane na topolojia ya NUMA ya seva (pNUMA). Utambuzi na suluhisho zinazowezekana za shida hii zimeandikwa, kwa mfano, katika kitabu . Ikiwa hutaki kwenda zaidi na huna vikwazo vya leseni kwenye OS iliyosanikishwa kwenye VM, tengeneza soketi nyingi za mtandaoni kwenye VM, msingi mmoja kwa wakati mmoja. Hautapoteza mengi :)
Hiyo yote ni kwangu kuhusu CPU. Uliza maswali. Katika sehemu inayofuata nitazungumza juu ya RAM.
Viungo muhimu
Chanzo: mapenzi.com