Kung nangangasiwa ka ng virtual na imprastraktura batay sa VMware vSphere (o anumang iba pang stack ng teknolohiya), malamang na madalas kang makarinig ng mga reklamo mula sa mga user: “Mabagal ang virtual machine!” Sa seryeng ito ng mga artikulo susuriin ko ang mga sukatan ng pagganap at sasabihin sa iyo kung ano at bakit ito bumagal at kung paano masisigurong hindi ito bumagal.
Isasaalang-alang ko ang mga sumusunod na aspeto ng pagganap ng virtual machine:
- CPU,
- RAM,
- DISK,
- Network.
Magsisimula ako sa CPU.
Upang pag-aralan ang pagganap kakailanganin namin:
- vCenter Performance Counter – mga performance counter, ang mga graph nito ay maaaring tingnan sa pamamagitan ng vSphere Client. Ang impormasyon sa mga counter na ito ay makukuha sa anumang bersyon ng client (“makapal” na client sa C#, web client sa Flex at web client sa HTML5). Sa mga artikulong ito ay gagamit kami ng mga screenshot mula sa C# client, dahil mas maganda ang hitsura nila sa miniature :)
- ESXTOP – isang utility na tumatakbo mula sa command line ng ESXi. Sa tulong nito, maaari mong makuha ang mga halaga ng mga counter ng pagganap sa real time o i-upload ang mga halagang ito para sa isang tiyak na panahon sa isang .csv file para sa karagdagang pagsusuri. Susunod, sasabihin ko sa iyo ang higit pa tungkol sa tool na ito at magbibigay ng ilang kapaki-pakinabang na link sa dokumentasyon at mga artikulo sa paksa.
Isang kaunting teorya
Sa ESXi, isang hiwalay na proseso – mundo sa terminolohiya ng VMware – ang responsable para sa pagpapatakbo ng bawat vCPU (virtual machine core). Mayroon ding mga proseso ng serbisyo, ngunit mula sa punto ng view ng pagsusuri sa pagganap ng VM ay hindi gaanong kawili-wili.
Ang isang proseso sa ESXi ay maaaring nasa isa sa apat na estado:
- Tumakbo – ang proseso ay nagsasagawa ng ilang kapaki-pakinabang na gawain.
- Maghintay – ang proseso ay walang ginagawa (idle) o naghihintay ng input/output.
- costtop – isang kondisyon na nangyayari sa mga multi-core virtual machine. Ito ay nangyayari kapag ang hypervisor CPU scheduler (ESXi CPU Scheduler) ay hindi makapag-iskedyul ng sabay-sabay na pagpapatupad ng lahat ng aktibong virtual machine core sa mga pisikal na server core. Sa pisikal na mundo, gumagana ang lahat ng mga core ng processor nang magkatulad, ang guest OS sa loob ng VM ay umaasa ng katulad na pag-uugali, kaya kailangang pabagalin ng hypervisor ang mga VM core na may kakayahang tapusin ang kanilang clock cycle nang mas mabilis. Sa modernong mga bersyon ng ESXi, ang CPU scheduler ay gumagamit ng mekanismong tinatawag na relaxed co-scheduling: isinasaalang-alang ng hypervisor ang agwat sa pagitan ng "pinakamabilis" at ang "pinakamabagal" na virtual machine core (skew). Kung ang gap ay lumampas sa isang tiyak na threshold, ang mabilis na core ay papasok sa costop na estado. Kung gumugugol ng maraming oras ang mga VM core sa ganitong estado, maaari itong magdulot ng mga isyu sa pagganap.
- Nakahanda – ang proseso ay pumapasok sa estadong ito kapag ang hypervisor ay hindi makapaglaan ng mga mapagkukunan para sa pagpapatupad nito. Maaaring magdulot ng mga problema sa performance ng VM ang mataas na ready value.
Mga pangunahing counter ng pagganap ng CPU ng virtual machine
Paggamit ng CPU, %. Ipinapakita ang porsyento ng paggamit ng CPU para sa isang partikular na panahon.
Paano mag-analyze? Kung ang isang VM ay patuloy na gumagamit ng CPU sa 90% o may mga peak hanggang 100%, magkakaroon tayo ng mga problema. Ang mga problema ay maaaring ipahayag hindi lamang sa "mabagal" na operasyon ng application sa loob ng VM, kundi pati na rin sa hindi naa-access ng VM sa network. Kung ipinapakita ng monitoring system na pana-panahong bumabagsak ang VM, bigyang-pansin ang mga peak sa graph ng Paggamit ng CPU.
Mayroong karaniwang Alarm na nagpapakita ng CPU load ng virtual machine:
Ano ang dapat gawin? Kung ang Paggamit ng CPU ng VM ay patuloy na dumadaan sa bubong, maaari mong isipin ang tungkol sa pagtaas ng bilang ng mga vCPU (sa kasamaang-palad, hindi ito palaging nakakatulong) o ilipat ang VM sa isang server na may mas malalakas na mga processor.
Paggamit ng CPU sa MHz
Sa mga graph sa vCenter Usage sa % makikita mo lamang para sa buong virtual machine; walang mga graph para sa mga indibidwal na core (sa Esxtop mayroong % na mga halaga para sa mga core). Para sa bawat core makikita mo ang Paggamit sa MHz.
Paano mag-analyze? Ito ay nangyayari na ang isang application ay hindi na-optimize para sa isang multi-core na arkitektura: ito ay gumagamit lamang ng isang core 100%, at ang iba ay idle nang walang load. Halimbawa, sa mga default na setting ng backup, sinisimulan ng MS SQL ang proseso sa isang core lamang. Bilang isang resulta, ang backup ay bumagal hindi dahil sa mabagal na bilis ng mga disk (ito ang unang inireklamo ng gumagamit), ngunit dahil ang processor ay hindi makayanan. Ang problema ay nalutas sa pamamagitan ng pagbabago ng mga parameter: ang backup ay nagsimulang tumakbo nang kahanay sa ilang mga file (ayon sa pagkakabanggit, sa ilang mga proseso).
Isang halimbawa ng hindi pantay na pagkarga sa mga core.
Mayroon ding isang sitwasyon (tulad ng sa graph sa itaas) kapag ang mga core ay na-load nang hindi pantay at ang ilan sa mga ito ay may mga peak na 100%. Tulad ng paglo-load lamang ng isang core, ang alarma para sa Paggamit ng CPU ay hindi gagana (ito ay para sa buong VM), ngunit magkakaroon ng mga problema sa pagganap.
Ano ang dapat gawin? Kung ang software sa isang virtual machine ay naglo-load ng mga core nang hindi pantay (gumagamit lamang ng isang core o bahagi ng mga core), walang saysay na dagdagan ang kanilang bilang. Sa kasong ito, mas mahusay na ilipat ang VM sa isang server na may mas malakas na mga processor.
Maaari mo ring subukang suriin ang mga setting ng paggamit ng kuryente sa BIOS ng server. Maraming mga administrador ang nagpapagana ng High Performance mode sa BIOS at sa gayon ay hindi pinagana ang mga C-state at P-state na mga teknolohiya sa pag-save ng enerhiya. Ang mga modernong processor ng Intel ay gumagamit ng teknolohiyang Turbo Boost, na nagpapataas ng dalas ng mga indibidwal na core ng processor sa gastos ng iba pang mga core. Ngunit gumagana lamang ito kapag naka-on ang mga teknolohiya sa pagtitipid ng enerhiya. Kung hindi namin paganahin ang mga ito, hindi mababawasan ng processor ang paggamit ng kuryente ng mga core na hindi na-load.
Inirerekomenda ng VMware na huwag paganahin ang mga teknolohiyang nagtitipid ng kuryente sa mga server, ngunit ang pagpili ng mga mode na nag-iiwan ng pamamahala ng kuryente sa hypervisor hangga't maaari. Sa kasong ito, sa mga setting ng paggamit ng kuryente ng hypervisor, kailangan mong piliin ang Mataas na Pagganap.
Kung mayroon kang mga indibidwal na VM (o mga VM core) sa iyong imprastraktura na nangangailangan ng pagtaas ng dalas ng CPU, ang wastong pagsasaayos ng paggamit ng kuryente ay maaaring makabuluhang mapabuti ang kanilang pagganap.
Handa na ang CPU
Kung ang VM core (vCPU) ay nasa Ready na estado, hindi ito gumaganap ng kapaki-pakinabang na gawain. Ang kundisyong ito ay nangyayari kapag ang hypervisor ay hindi nakahanap ng libreng pisikal na core kung saan maaaring italaga ang proseso ng vCPU ng virtual machine.
Paano mag-analyze? Karaniwan, kung ang mga core ng virtual machine ay nasa Ready state nang higit sa 10% ng oras, mapapansin mo ang mga isyu sa pagganap. Sa madaling salita, higit sa 10% ng oras na naghihintay ang VM para maging available ang mga pisikal na mapagkukunan.
Sa vCenter maaari mong tingnan ang 2 counter na may kaugnayan sa CPU Ready:
- kahandaan,
- Handa.
Ang mga halaga ng parehong mga counter ay maaaring matingnan kapwa para sa buong VM at para sa mga indibidwal na core.
Ang pagiging handa ay nagpapakita ng halaga kaagad bilang isang porsyento, ngunit sa Real-time lamang (data para sa huling oras, pagitan ng pagsukat na 20 segundo). Mas mainam na gamitin ang counter na ito lamang upang maghanap ng mga problema na "mainit sa takong".
Ang mga handa na counter value ay maaari ding tingnan mula sa isang makasaysayang pananaw. Ito ay kapaki-pakinabang para sa pagtatatag ng mga pattern at para sa mas malalim na pagsusuri ng problema. Halimbawa, kung ang isang virtual machine ay nagsimulang makaranas ng mga problema sa pagganap sa isang partikular na oras, maaari mong ihambing ang mga pagitan ng halaga ng CPU Ready sa kabuuang pag-load sa server kung saan tumatakbo ang VM na ito, at gumawa ng mga hakbang upang bawasan ang pag-load (kung DRS nabigo).
Ang Handa, hindi katulad ng Readiness, ay ipinapakita hindi sa mga porsyento, ngunit sa mga millisecond. Isa itong Summation type counter, ibig sabihin, ipinapakita nito kung gaano katagal sa panahon ng pagsukat ang VM core ay nasa Ready state. Maaari mong i-convert ang halagang ito sa isang porsyento gamit ang isang simpleng formula:
(CPU ready summation value / (chart default update interval in seconds * 1000)) * 100 = CPU ready %
Halimbawa, para sa VM sa graph sa ibaba, ang peak Ready value para sa buong virtual machine ay magiging ganito:
Kapag kinakalkula ang porsyento ng Handa, dapat mong bigyang pansin ang dalawang puntos:
- Ang Ready value para sa buong VM ay ang kabuuan ng Ready sa mga core.
- pagitan ng pagsukat. Para sa Real-time ito ay 20 segundo, at, halimbawa, sa mga pang-araw-araw na chart ito ay 300 segundo.
Sa aktibong pag-troubleshoot, ang mga simpleng puntong ito ay madaling makaligtaan at ang mahalagang oras ay maaaring masayang sa paglutas ng mga hindi umiiral na problema.
Kalkulahin natin ang Ready batay sa data mula sa graph sa ibaba. (324474/(20*1000))*100 = 1622% para sa buong VM. Kung titingnan mo ang mga core, hindi ito nakakatakot: 1622/64 = 25% bawat core. Sa kasong ito, ang catch ay medyo madaling makita: ang Ready value ay hindi makatotohanan. Ngunit kung pinag-uusapan natin ang tungkol sa 10–20% para sa buong VM na may ilang mga core, kung gayon para sa bawat core ang halaga ay maaaring nasa loob ng normal na hanay.
Ano ang dapat gawin? Ang mataas na halaga ng Ready ay nagpapahiwatig na ang server ay walang sapat na mapagkukunan ng processor para sa normal na operasyon ng mga virtual machine. Sa ganoong sitwasyon, ang natitira na lang ay bawasan ang labis na subscription ng processor (vCPU:pCPU). Malinaw, ito ay maaaring makamit sa pamamagitan ng pagbabawas ng mga parameter ng mga umiiral na VM o sa pamamagitan ng paglipat ng bahagi ng mga VM sa iba pang mga server.
Magkasabay na huminto
Paano mag-analyze? Ang counter na ito ay nasa uri din ng Summation at na-convert sa mga porsyento sa parehong paraan tulad ng Ready:
(CPU co-stop summation value / (chart default update interval in seconds * 1000)) * 100 = CPU co-stop %
Dito kailangan mo ring bigyang pansin ang bilang ng mga core sa VM at ang agwat ng pagsukat.
Sa costop state, ang kernel ay hindi gumaganap ng kapaki-pakinabang na gawain. Sa tamang pagpili ng laki ng VM at normal na pag-load sa server, dapat malapit sa zero ang co-stop counter.
Sa kasong ito, ang pag-load ay malinaw na abnormal :)
Ano ang dapat gawin? Kung maraming VM na may malaking bilang ng mga core ay tumatakbo sa isang hypervisor at mayroong labis na subscription sa CPU, maaaring tumaas ang co-stop counter, na hahantong sa mga problema sa pagganap ng mga VM na ito.
Gayundin, tataas ang co-stop kung ang mga aktibong core ng isang VM ay gumagamit ng mga thread sa isang pisikal na core ng server na may naka-enable na hyper-treading. Maaaring lumitaw ang sitwasyong ito, halimbawa, kung ang VM ay may mas maraming mga core kaysa pisikal na magagamit sa server kung saan ito tumatakbo, o kung ang setting na "preferHT" ay pinagana para sa VM. Mababasa mo ang tungkol sa setting na ito .
Upang maiwasan ang mga problema sa pagganap ng VM dahil sa mataas na co-stop, piliin ang laki ng VM alinsunod sa mga rekomendasyon ng tagagawa ng software na tumatakbo sa VM na ito at ang mga kakayahan ng pisikal na server kung saan tumatakbo ang VM.
Huwag magdagdag ng mga core sa reserba; maaari itong magdulot ng mga problema sa pagganap hindi lamang para sa VM mismo, kundi pati na rin para sa mga kapitbahay nito sa server.
Iba pang mga kapaki-pakinabang na sukatan ng CPU
Tumakbo – kung gaano katagal (ms) sa panahon ng pagsukat ang vCPU ay nasa RUN state, ibig sabihin, ito ay aktwal na gumaganap ng kapaki-pakinabang na gawain.
Walang ginagawa – gaano katagal (ms) sa panahon ng pagsukat ang vCPU ay nasa isang estado ng hindi aktibo. Ang mga mataas na halaga ng Idle ay hindi isang problema, ang vCPU ay "walang gagawin."
Maghintay – gaano katagal (ms) sa panahon ng pagsukat ang vCPU ay nasa status ng Wait. Dahil ang IDLE ay kasama sa counter na ito, ang mataas na Wait values ay hindi rin nagpapahiwatig ng problema. Ngunit kung mababa ang Wait IDLE kapag mataas ang Wait, nangangahulugan ito na naghihintay ang VM para makumpleto ang mga operasyon ng I/O, at ito naman, ay maaaring magpahiwatig ng problema sa performance ng hard drive o anumang virtual device ng VM.
Max limitado – gaano katagal (ms) sa panahon ng pagsukat ang vCPU ay nasa Ready state dahil sa itinakdang resource limit. Kung ang pagganap ay hindi maipaliwanag na mababa, pagkatapos ay kapaki-pakinabang na suriin ang halaga ng counter na ito at ang limitasyon ng CPU sa mga setting ng VM. Maaaring may mga limitasyon talaga ang mga VM na hindi mo alam. Halimbawa, nangyayari ito kapag na-clone ang isang VM mula sa isang template kung saan itinakda ang limitasyon ng CPU.
Magpalit ng paghihintay – gaano katagal sa panahon ng pagsukat ang vCPU ay naghintay para sa isang operasyon sa VMkernel Swap. Kung ang mga halaga ng counter na ito ay higit sa zero, kung gayon ang VM ay tiyak na may mga problema sa pagganap. Pag-uusapan natin ang higit pa tungkol sa SWAP sa artikulo tungkol sa mga counter ng RAM.
ESXTOP
Kung ang mga counter ng pagganap sa vCenter ay mabuti para sa pagsusuri ng makasaysayang data, kung gayon ang pagsusuri sa pagpapatakbo ng problema ay mas mahusay na gawin sa ESXTOP. Dito, ang lahat ng mga halaga ay ipinakita sa handa na form (hindi na kailangang isalin ang anuman), at ang pinakamababang panahon ng pagsukat ay 2 segundo.
Ang ESXTOP screen para sa CPU ay tinatawag na may "c" key at ganito ang hitsura:
Para sa kaginhawahan, maaari kang mag-iwan lamang ng mga proseso ng virtual machine sa pamamagitan ng pagpindot sa Shift-V.
Upang tingnan ang mga sukatan para sa mga indibidwal na VM core, pindutin ang “e” at ilagay ang GID ng VM ng interes (30919 sa screenshot sa ibaba):
Hayaan akong dumaan sa maikling mga column na ipinakita bilang default. Maaaring magdagdag ng mga karagdagang column sa pamamagitan ng pagpindot sa "f".
NWLD (Bilang ng Mundo) – bilang ng mga proseso sa pangkat. Upang palawakin ang pangkat at makita ang mga sukatan para sa bawat proseso (halimbawa, para sa bawat core sa isang multi-core VM), pindutin ang “e”. Kung mayroong higit sa isang proseso sa isang pangkat, ang mga halaga ng sukatan para sa pangkat ay katumbas ng kabuuan ng mga sukatan para sa mga indibidwal na proseso.
%GINAMIT – kung gaano karaming mga siklo ng CPU ng server ang ginagamit ng isang proseso o pangkat ng mga proseso.
%TAKBO – gaano katagal sa panahon ng pagsukat ang proseso ay nasa RUN state, i.e. gumawa ng kapaki-pakinabang na gawain. Naiiba ito sa %USED dahil hindi nito isinasaalang-alang ang hyper-threading, frequency scaling at oras na ginugol sa mga gawain ng system (%SYS).
%SYS – oras na ginugol sa mga gawain ng system, halimbawa: pag-abala sa pagproseso, I/O, pagpapatakbo ng network, atbp. Maaaring mataas ang halaga kung ang VM ay may malaking I/O.
%OVRLP – gaano katagal ginugugol ang pisikal na core kung saan tumatakbo ang proseso ng VM sa mga gawain ng iba pang mga proseso.
Ang mga sukatan na ito ay nauugnay sa isa't isa gaya ng sumusunod:
%USED = %RUN + %SYS - %OVRLP.
Karaniwan ang %USED na sukatan ay mas nagbibigay-kaalaman.
%WAIT – gaano katagal sa panahon ng pagsukat ang proseso ay nasa status ng Wait. Pinapagana ang IDLE.
%WALANG GINAGAWA – gaano katagal sa panahon ng pagsukat ang proseso ay nasa IDLE state.
%SWPWT – gaano katagal sa panahon ng pagsukat ang vCPU ay naghintay para sa isang operasyon sa VMkernel Swap.
%VMWAIT – gaano katagal sa panahon ng pagsukat ang vCPU ay nasa estado ng paghihintay para sa isang kaganapan (karaniwan ay I/O). Walang katulad na counter sa vCenter. Ang mga mataas na halaga ay nagpapahiwatig ng mga problema sa I/O sa VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Kung ang VM ay hindi gumagamit ng VMkernel Swap, kung gayon kapag sinusuri ang mga problema sa pagganap, ipinapayong tingnan ang %VMWAIT, dahil ang sukatan na ito ay hindi isinasaalang-alang ang oras kung kailan ang VM ay walang ginagawa (%IDLE).
%RDY – gaano katagal sa panahon ng pagsukat ang proseso ay nasa Ready state.
%CSTP – gaano katagal sa panahon ng pagsukat ang proseso ay nasa costop state.
%MLMTD – gaano katagal sa panahon ng pagsukat ang vCPU ay nasa Ready state dahil sa itinakdang resource limit.
%WAIT + %RDY + %CSTP + %RUN = 100% – ang VM core ay palaging nasa isa sa apat na estadong ito.
CPU sa hypervisor
Ang vCenter ay mayroon ding mga CPU performance counter para sa hypervisor, ngunit ang mga ito ay walang interesante - ang mga ito ay ang kabuuan lamang ng mga counter para sa lahat ng VM sa server.
Ang pinaka-maginhawang paraan upang tingnan ang status ng CPU sa server ay nasa tab na Buod:
Para sa server, pati na rin para sa virtual machine, mayroong isang karaniwang Alarm:
Kapag mataas ang pag-load ng CPU ng server, ang mga VM na tumatakbo dito ay magsisimulang makaranas ng mga problema sa pagganap.
Sa ESXTOP, ipinapakita ang data ng pag-load ng CPU ng server sa tuktok ng screen. Bilang karagdagan sa karaniwang pag-load ng CPU, na hindi masyadong nagbibigay-kaalaman para sa mga hypervisors, may tatlo pang sukatan:
CORE UTIL(%) – nilo-load ang pisikal na server core. Ipinapakita ng counter na ito kung gaano katagal gumanap ang core sa panahon ng pagsukat.
PCPU UTIL(%) – kung naka-enable ang hyper-threading, mayroong dalawang thread (PCPU) bawat pisikal na core. Ipinapakita ng sukatang ito kung gaano katagal bago matapos ang gawain ng bawat thread.
GINAMIT na PCPU(%) – kapareho ng PCPU UTIL(%), ngunit isinasaalang-alang ang frequency scaling (alinman sa pagbabawas ng core frequency para sa mga layunin ng pagtitipid ng enerhiya, o pagtaas ng core frequency dahil sa Turbo Boost technology) at hyper-threading.
PCPU_USED% = PCPU_UTIL% * epektibong core frequency / nominal core frequency.
Sa screenshot na ito, para sa ilang mga core, dahil sa Turbo Boost, ang USED value ay mas mataas sa 100%, dahil ang core frequency ay mas mataas kaysa sa nominal.
Ilang salita tungkol sa kung paano isinasaalang-alang ang hyper-threading. Kung ang mga proseso ay isinasagawa nang 100% ng oras sa parehong mga thread ng pisikal na core ng server, habang ang core ay gumagana sa nominal na dalas, kung gayon:
- Ang CORE UTIL para sa core ay magiging 100%,
- Ang PCPU UTIL para sa parehong mga thread ay magiging 100%,
- Ang PCPU na GINAMIT para sa parehong mga thread ay magiging 50%.
Kung ang parehong mga thread ay hindi gumana nang 100% ng oras sa panahon ng pagsukat, pagkatapos ay sa mga panahong iyon na ang mga thread ay gumana nang magkatulad, ang PCPU na GINAMIT para sa mga core ay nahahati sa kalahati.
Ang ESXTOP ay mayroon ding screen na may mga parameter ng pagkonsumo ng kuryente ng CPU ng server. Dito makikita mo kung gumagamit ang server ng mga teknolohiyang nagtitipid ng enerhiya: C-states at P-states. Tinatawag gamit ang "p" key:
Mga Karaniwang Isyu sa Pagganap ng CPU
Sa wakas, tatalakayin ko ang mga karaniwang sanhi ng mga problema sa pagganap ng VM CPU at magbibigay ng maiikling tip para sa paglutas sa mga ito:
Ang pangunahing bilis ng orasan ay hindi sapat. Kung hindi posible na i-upgrade ang iyong VM sa mas mahuhusay na mga core, maaari mong subukang baguhin ang mga setting ng kapangyarihan upang gawing mas mahusay ang Turbo Boost.
Maling sukat ng VM (masyadong marami/kaunting mga core). Kung mag-i-install ka ng ilang mga core, magkakaroon ng mataas na pag-load ng CPU sa VM. Kung marami, sumakay ng mataas na co-stop.
Malaking oversubscription ng CPU sa server. Kung ang VM ay may mataas na Ready, bawasan ang oversubscription ng CPU.
Maling NUMA topology sa malalaking VM. Ang NUMA topology na nakikita ng VM (vNUMA) ay dapat tumugma sa NUMA topology ng server (pNUMA). Ang mga diagnostic at posibleng solusyon sa problemang ito ay nakasulat, halimbawa, sa aklat . Kung ayaw mong lumalim pa at wala kang mga paghihigpit sa paglilisensya sa OS na naka-install sa VM, gumawa ng maraming virtual socket sa VM, isang core sa isang pagkakataon. Hindi ka masyadong mawawala :)
Iyon lang ang para sa akin tungkol sa CPU. Magtanong. Sa susunod na bahagi ay magsasalita ako tungkol sa RAM.
Kapaki-pakinabang na mga link
Pinagmulan: www.habr.com