Ef þú stjórnar sýndarinnviði sem byggir á VMware vSphere (eða öðrum tæknistafla), heyrirðu líklega oft kvartanir frá notendum: „Sýndarvélin er hæg! Í þessari greinaröð mun ég greina árangursmælingar og segja þér hvað og hvers vegna það hægist á og hvernig á að tryggja að það hægist ekki á.
Ég mun íhuga eftirfarandi þætti í frammistöðu sýndarvéla:
- CPU,
- VINNSLUMINNI,
- DISK,
- Net.
Ég byrja á CPU.
Til að greina frammistöðu þurfum við:
- vCenter árangursteljarar – árangursteljarar, hægt er að skoða línurit þeirra í gegnum vSphere Client. Upplýsingar um þessa teljara eru fáanlegar í hvaða útgáfu sem er af biðlaranum („þykkur“ viðskiptavinur í C#, vefbiðlari í Flex og vefbiðlari í HTML5). Í þessum greinum munum við nota skjámyndir frá C# biðlaranum, aðeins vegna þess að þær líta betur út í litlum myndum :)
- ESXTOP – tól sem keyrir frá ESXi skipanalínunni. Með hjálp þess geturðu fengið gildi frammistöðuteljara í rauntíma eða hlaðið þessum gildum upp í ákveðinn tíma í .csv skrá til frekari greiningar. Næst mun ég segja þér meira um þetta tól og veita nokkra gagnlega tengla á skjöl og greinar um efnið.
Smá kenning
Í ESXi er sérstakt ferli - heimur í VMware hugtökum - ábyrgur fyrir rekstri hvers vCPU (sýndarvélkjarna). Það eru líka þjónustuferli, en frá sjónarhóli að greina frammistöðu VM eru þau minna áhugaverð.
Ferli í ESXi getur verið í einu af fjórum ríkjum:
- Hlaupa - ferlið skilar gagnlegri vinnu.
- Bíddu – ferlið er ekki að vinna neina vinnu (aðgerðalaus) eða bíður eftir inntak/úttak.
- Costop – ástand sem á sér stað í sýndarvélum með mörgum kjarna. Það gerist þegar örgjörvaáætlunarstjóri (ESXi CPU tímaáætlun) getur ekki tímasett samtímis framkvæmd allra virkra sýndarvélarkjarna á efnislegum miðlarakjörnum. Í efnisheiminum virka allir örgjörvakjarnar samhliða, gestastýrikerfið inni í VM býst við svipaðri hegðun, þannig að hypervisorinn þarf að hægja á VM kjarnanum sem hafa getu til að klára klukkulotuna sína hraðar. Í nútíma útgáfum af ESXi notar CPU tímaáætlunarkerfið vélbúnað sem kallast slaka samáætlun: yfirsýnarmaðurinn telur bilið á milli „hraðasta“ og „hægasta“ sýndarvélarkjarna (skekktur). Ef bilið fer yfir ákveðinn þröskuld fer hraðkjarninn í costop ástandið. Ef VM kjarna eyða miklum tíma í þessu ástandi getur það valdið frammistöðuvandamálum.
- Tilbúinn – ferlið fer í þetta ástand þegar yfirsýnarinn getur ekki úthlutað fjármagni fyrir framkvæmd þess. Há tilbúin gildi geta valdið vandamálum með afköst VM.
Grunnmælir örgjörva sýndarvélar
Örgjörvanotkun, %. Sýnir hlutfall örgjörvanotkunar fyrir tiltekið tímabil.
Hvernig á að greina? Ef VM notar stöðugt CPU í 90% eða það eru toppar allt að 100%, þá erum við í vandræðum. Vandamál geta ekki aðeins komið fram í „hægri“ notkun forritsins inni í VM, heldur einnig í óaðgengilegri VM yfir netið. Ef vöktunarkerfið sýnir að VM dettur reglulega af, gaum að toppunum í CPU notkun línuritinu.
Það er staðlað viðvörun sem sýnir örgjörvaálag sýndarvélarinnar:
Hvað á að gera? Ef örgjörvanotkun VM er stöðugt að fara í gegnum þakið, þá geturðu hugsað um að fjölga vCPUs (því miður hjálpar þetta ekki alltaf) eða færa VM á netþjón með öflugri örgjörva.
Örgjörvanotkun í MHz
Í línuritum á vCenter notkun í % geturðu aðeins séð fyrir alla sýndarvélina; það eru engin línurit fyrir einstaka kjarna (í Esxtop eru % gildi fyrir kjarna). Fyrir hvern kjarna er hægt að sjá Notkun í MHz.
Hvernig á að greina? Það gerist að forrit er ekki fínstillt fyrir fjölkjarna arkitektúr: það notar aðeins einn kjarna 100% og restin er aðgerðalaus án álags. Til dæmis, með sjálfgefnum öryggisafritunarstillingum, byrjar MS SQL ferlið á aðeins einum kjarna. Fyrir vikið hægist öryggisafritið ekki vegna hægs hraða diskanna (þetta er það sem notandinn kvartaði yfir í upphafi), heldur vegna þess að örgjörvinn ræður ekki við. Vandamálið var leyst með því að breyta breytum: öryggisafrit byrjaði að keyra samhliða í nokkrum skrám (í sömu röð, í nokkrum ferlum).
Dæmi um ójafnt álag á kjarna.
Það er líka sú staða (eins og á grafinu hér að ofan) að kjarnarnir eru hlaðnir ójafnt og sumir þeirra hafa toppa upp á 100%. Eins og með að hlaða aðeins einum kjarna, mun viðvörunin fyrir CPU notkun ekki virka (hún er fyrir alla VM), en það verða afköst vandamál.
Hvað á að gera? Ef hugbúnaðurinn í sýndarvél hleður kjarnana ójafnt (notar aðeins einn kjarna eða hluta af kjarnanum) þýðir ekkert að fjölga þeim. Í þessu tilviki er betra að færa VM á netþjón með öflugri örgjörva.
Þú getur líka prófað að athuga orkunotkunarstillingarnar í BIOS miðlarans. Margir stjórnendur virkja High Performance ham í BIOS og slökkva þannig á C-state og P-state orkusparnaðartækni. Nútíma Intel örgjörvar nota Turbo Boost tækni, sem eykur tíðni einstakra örgjörvakjarna á kostnað annarra kjarna. En það virkar aðeins þegar kveikt er á orkusparnaðartækni. Ef við slökkva á þeim getur örgjörvinn ekki dregið úr orkunotkun kjarna sem eru ekki hlaðnir.
VMware mælir með því að slökkva ekki á orkusparandi tækni á netþjónum, heldur að velja stillingar sem skilja orkustjórnunina eftir eins mikið og mögulegt er. Í þessu tilviki, í orkunotkunarstillingum hypervisor, þarftu að velja High Performance.
Ef þú ert með einstaka VM (eða VM kjarna) í innviðum þínum sem krefjast aukinnar CPU tíðni, getur rétt aðlögun orkunotkunar bætt afköst þeirra verulega.
CPU tilbúinn
Ef VM kjarninn (vCPU) er í tilbúinn ástandi, framkvæmir hann ekki gagnlega vinnu. Þetta ástand á sér stað þegar hypervisor finnur ekki ókeypis líkamlegan kjarna sem hægt er að úthluta vCPU ferli sýndarvélarinnar til.
Hvernig á að greina? Venjulega, ef kjarni sýndarvélar er í tilbúnu ástandi meira en 10% tilvika, muntu taka eftir afköstum. Einfaldlega sagt, meira en 10% af þeim tíma sem VM bíður eftir að efnisleg úrræði verða tiltæk.
Í vCenter er hægt að skoða 2 teljara sem tengjast CPU Ready:
- reiðubúin,
- Tilbúinn.
Hægt er að skoða gildi beggja teljara bæði fyrir allan VM og einstaka kjarna.
Viðbúnaður sýnir gildið strax sem prósentu, en aðeins í rauntíma (gögn fyrir síðustu klukkustund, mælingarbil 20 sekúndur). Það er betra að nota þennan teljara eingöngu til að leita að vandamálum „heitt á hælunum“.
Einnig er hægt að skoða tilbúin teljaragildi frá sögulegu sjónarhorni. Þetta er gagnlegt til að koma á mynstrum og til dýpri greiningar á vandamálinu. Til dæmis, ef sýndarvél fer að lenda í afköstum á ákveðnum tíma, geturðu borið saman millibil CPU Ready gildisins við heildarálag á þjóninn þar sem þessi VM er í gangi og gert ráðstafanir til að draga úr álaginu (ef DRS mistekst).
Tilbúinn, ólíkt tilbúinn, er ekki sýndur í prósentum, heldur í millisekúndum. Þetta er samantektarteljari, það er að segja hann sýnir hversu lengi á mælitímabilinu VM kjarninn var í tilbúnu ástandi. Þú getur umbreytt þessu gildi í prósentu með því að nota einfalda formúlu:
(CPU tilbúið samantektargildi / (sjálfgefið uppfærslubil á töflu í sekúndum * 1000)) * 100 = CPU tilbúið %
Til dæmis, fyrir VM á línuritinu hér að neðan, verður hámarks tilbúið gildi fyrir alla sýndarvélina sem hér segir:
Þegar þú reiknar út tilbúna prósentuna ættir þú að borga eftirtekt til tveggja punkta:
- Tilbúið gildi fyrir allan VM er summan af Tilbúnum yfir kjarna.
- Mælingarbil. Fyrir rauntíma er það 20 sekúndur og til dæmis á daglegum kortum er það 300 sekúndur.
Með virkri bilanaleit má auðveldlega missa af þessum einföldu punktum og dýrmætum tíma eyða í að leysa vandamál sem ekki eru til.
Við skulum reikna Ready út frá gögnunum úr línuritinu hér að neðan. (324474/(20*1000))*100 = 1622% fyrir allan VM. Ef þú horfir á kjarnana er það ekki svo skelfilegt: 1622/64 = 25% á hvern kjarna. Í þessu tilviki er auðvelt að koma auga á veiðina: Ready gildið er óraunhæft. En ef við erum að tala um 10–20% fyrir allan VM með nokkrum kjarna, þá getur gildið fyrir hvern kjarna verið innan eðlilegra marka.
Hvað á að gera? Hátt tilbúið gildi gefur til kynna að þjónninn hafi ekki nægjanlegt örgjörvatilföng fyrir eðlilega notkun sýndarvéla. Í slíkum aðstæðum er allt sem eftir er að draga úr ofáskrift eftir örgjörva (vCPU:pCPU). Augljóslega er hægt að ná þessu með því að minnka færibreytur núverandi VM eða með því að flytja hluta af VM til annarra netþjóna.
Co-stop
Hvernig á að greina? Þessi teljari er einnig af gerðinni Summation og er umreiknaður í prósentur á sama hátt og Tilbúinn:
(CPU co-stop summanation value / (sjálfgefið uppfærslubil töflu í sekúndum * 1000)) * 100 = CPU co-stop %
Hér þarf líka að huga að fjölda kjarna á VM og mælibilinu.
Í costop ástandinu framkvæmir kjarninn ekki gagnlega vinnu. Með réttu vali á stærð VM og venjulegu álagi á þjóninum ætti stöðvunarteljarinn að vera nálægt núlli.
Í þessu tilfelli er álagið greinilega óeðlilegt :)
Hvað á að gera? Ef nokkrir VMs með mikinn fjölda kjarna eru í gangi á einum hypervisor og það er ofáskrift á örgjörvanum, þá gæti stöðvunarteljarinn hækkað, sem mun leiða til vandamála með afköst þessara VMs.
Samhliða stöðvun mun einnig aukast ef virkir kjarna eins VM notar þræði á einum líkamlegum miðlarakjarna með ofþroska virkt. Þessi staða getur komið upp, til dæmis ef VM hefur fleiri kjarna en efnislega tiltækar á þjóninum þar sem hann er í gangi, eða ef „preferHT“ stillingin er virkjuð fyrir VM. Þú getur lesið um þessa stillingu .
Til að forðast vandamál með afköst VM vegna mikillar samtengingar, veldu VM stærð í samræmi við ráðleggingar framleiðanda hugbúnaðarins sem keyrir á þessum VM og getu líkamlega netþjónsins þar sem VM keyrir.
Ekki bæta við kjarna í varasjóði; þetta getur valdið afköstum, ekki aðeins fyrir VM sjálfan, heldur einnig fyrir nágranna hans á þjóninum.
Aðrar gagnlegar örgjörvamælingar
Hlaupa – hversu mikinn tíma (ms) á mælitímabilinu vCPU var í RUN ástandi, það er að segja að hann var í raun að vinna gagnlega vinnu.
Aðgerðalaus – hversu lengi (ms) á mælitímabilinu vCPU var í óvirkni. Hátt Idle gildi eru ekki vandamál, vCPU hafði bara „ekkert að gera“.
Bíddu – hversu lengi (ms) á mælitímabilinu vCPU var í biðstöðu. Þar sem IDLE er innifalið í þessum teljara gefa há biðgildi heldur ekki til kynna vandamál. En ef Wait IDLE er lágt þegar Wait er hátt þýðir það að VM beið eftir að I/O aðgerðum yrði lokið, og það gæti aftur á móti bent til vandamála með afköst harða disksins eða sýndartækja VM.
Hámark takmarkað – hversu lengi (ms) á mælitímabilinu vCPU var í tilbúnu ástandi vegna uppsettra auðlindatakmarka. Ef frammistaða er óútskýranlega lág, þá er gagnlegt að athuga gildi þessa teljara og CPU takmörk í VM stillingum. VMs gætu örugglega haft takmörk sem þú ert ekki meðvitaður um. Til dæmis gerist þetta þegar VM var klónað úr sniðmáti þar sem CPU takmörkin voru sett á.
Skipta bið – hversu lengi á mælitímanum beið vCPU eftir aðgerð með VMkernel Swap. Ef gildi þessa teljara eru yfir núllinu, þá á VM örugglega við frammistöðuvandamál að stríða. Við munum tala meira um SWAP í greininni um vinnsluminni teljara.
ESXTOP
Ef frammistöðuteljarar í vCenter eru góðir til að greina söguleg gögn, þá er rekstrargreining á vandamálinu betur unnin í ESXTOP. Hér eru öll gildi sett fram á tilbúnu formi (ekki þarf að þýða neitt) og lágmarks mælingartími er 2 sekúndur.
ESXTOP skjárinn fyrir CPU er kallaður upp með "c" takkanum og lítur svona út:
Til þæginda geturðu aðeins skilið eftir sýndarvélarferli með því að ýta á Shift-V.
Til að skoða mælikvarða fyrir einstaka VM kjarna, ýttu á „e“ og sláðu inn GID þess VM sem þú vilt (30919 á skjámyndinni hér að neðan):
Leyfðu mér að fara stuttlega í gegnum dálkana sem eru sýndir sjálfgefið. Hægt er að bæta við fleiri dálkum með því að ýta á "f".
NWLD (Fjöldi heima) – fjöldi ferla í hópnum. Til að stækka hópinn og sjá mælikvarða fyrir hvert ferli (til dæmis fyrir hvern kjarna í fjölkjarna VM), ýttu á „e“. Ef það eru fleiri en eitt ferli í hópi, þá eru mæligildi fyrir hópinn jöfn summu mæligildanna fyrir einstaka ferla.
%NOTAÐ – hversu margar örgjörvalotur miðlara eru notaðar af ferli eða hópi ferla.
% RUN – hversu lengi á mælitímabilinu ferlið var í RUN ástandi, þ.e. vann gagnlegt starf. Það er frábrugðið %USED að því leyti að það tekur ekki tillit til ofþráðs, tíðniskalunar og tíma sem varið er í kerfisverkefni (%SYS).
%SYS – tími sem varið er í kerfisverkefni, til dæmis: trufla vinnslu, I/O, netrekstur osfrv. Gildið getur verið hátt ef VM er með stórt I/O.
%OVRLP – hversu miklum tíma efnislegi kjarninn sem VM ferlið er í gangi á eyddi í verkefni annarra ferla.
Þessar mælingar tengjast hver öðrum sem hér segir:
%NOTAÐ = %RUN + %SYS - %OVRLP.
Venjulega er mæligildið %USED upplýsandi.
% BÍÐA – hversu lengi á mælitímabilinu ferlið var í biðstöðu. Virkjar IDLE.
%AÐGERÐ – hversu lengi á mælitímabilinu ferlið var í aðgerðalausu ástandi.
%SWPWT – hversu lengi á mælitímanum beið vCPU eftir aðgerð með VMkernel Swap.
%VMWAIT – hversu lengi á mælitímabilinu vCPU var í því ástandi að bíða eftir atburði (venjulega I/O). Það er enginn svipaður teljari í vCenter. Há gildi gefa til kynna vandamál með I/O á VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Ef VM notar ekki VMkernel Swap, þá er ráðlegt að horfa á %VMWAIT þegar verið er að greina árangursvandamál, þar sem þessi mælikvarði tekur ekki tillit til þess tíma þegar VM var að gera ekkert (%IDLE).
%RDY – hversu lengi á mælitímabilinu ferlið var í tilbúnu ástandi.
%CSTP – hversu lengi á mælitímabilinu ferlið var í kostnaðarástandi.
%MLMTD – hversu lengi á mælitímabilinu vCPU var í tilbúnu ástandi vegna uppsettra auðlindatakmarka.
%WAIT + %RDY + %CSTP + %RUN = 100% – VM kjarninn er alltaf í einu af þessum fjórum stöðum.
CPU á hypervisor
vCenter hefur líka CPU-afköstteljara fyrir hypervisorinn, en þeir eru ekkert áhugaverðir - þeir eru einfaldlega summa teljara allra VM á þjóninum.
Þægilegasta leiðin til að skoða CPU stöðu á þjóninum er á Yfirlit flipanum:
Fyrir netþjóninn, sem og fyrir sýndarvélina, er staðlað viðvörun:
Þegar örgjörvaálag þjónsins er mikið byrja tölvurnar sem keyra á honum að lenda í afköstum.
Í ESXTOP eru CPU hleðslugögn netþjóns sýnd efst á skjánum. Til viðbótar við staðlaða örgjörvaálag, sem er ekki mjög upplýsandi fyrir hypervisors, eru þrjár mælingar í viðbót:
KJARNANIT(%) – hleður líkamlega netþjónskjarnanum. Þessi teljari sýnir hversu mikinn tíma kjarninn vann vinnu á mælitímabilinu.
PCPU UTIL(%) – ef ofur-þráður er virkur, þá eru tveir þræðir (PCPU) fyrir hvern líkamlegan kjarna. Þessi mælikvarði sýnir hversu langan tíma það tók hvern þráð að klára vinnu.
PCPU NOTAÐ(%) – sama og PCPU UTIL(%), en tekur tillit til tíðniskalunar (annaðhvort minnkar kjarnatíðnina í orkusparnaðarskyni, eða eykur kjarnatíðnina vegna Turbo Boost tækni) og ofurþráðs.
PCPU_USED% = PCPU_UTIL% * virk kjarnatíðni / nafnkjarnatíðni.
Í þessari skjámynd, fyrir suma kjarna, vegna Turbo Boost, er USED gildið meira en 100%, þar sem kjarnatíðnin er hærri en nafntíðnin.
Nokkur orð um hvernig tekið er tillit til ofþráðs. Ef ferlar eru keyrðir 100% af tímanum á báðum þráðum efniskjarna þjónsins, á meðan kjarninn starfar á nafntíðni, þá:
- CORE UTIL fyrir kjarnann verður 100%,
- PCPU UTIL fyrir báða þræðina verður 100%,
- PCPU NOTAÐUR fyrir báða þræðina verður 50%.
Ef báðir þræðir virkuðu ekki 100% af tímanum á mælitímabilinu, þá á þeim tímabilum sem þræðirnir virkuðu samhliða, er PCPU sem notaður er fyrir kjarnana skipt í tvennt.
ESXTOP er einnig með skjá með breytum fyrir orkunotkun netþjóns CPU. Hér getur þú séð hvort þjónninn notar orkusparnaðartækni: C-ríki og P-ríki. Hringt með "p" takkanum:
Algeng vandamál með afköst CPU
Að lokum mun ég fara yfir dæmigerðar orsakir vandamála með afköst VM CPU og gefa stutt ráð til að leysa þau:
Kjarnaklukkuhraði er ekki nóg. Ef það er ekki hægt að uppfæra VM þinn í öflugri kjarna geturðu prófað að breyta aflstillingunum til að láta Turbo Boost virka á skilvirkari hátt.
Röng stærð VM (of margir/fáir kjarna). Ef þú setur upp fáa kjarna verður mikið CPU álag á VM. Ef það er mikið, gríptu háa samstöðu.
Mikil ofáskrift af CPU á þjóninum. Ef VM er með hátt tilbúinn skaltu draga úr ofáskrift CPU.
Röng NUMA staðfræði á stórum VM. NUMA svæðisfræðin sem VM sér (vNUMA) verður að passa við NUMA svæðisfræði þjónsins (pNUMA). Greining og mögulegar lausnir á þessu vandamáli eru til dæmis skrifaðar í bókina . Ef þú vilt ekki fara dýpra og þú ert ekki með leyfistakmarkanir á stýrikerfinu sem er uppsett á VM, búðu til margar sýndarinnstungur á VM, einn kjarna í einu. Þú tapar ekki miklu :)
Það er allt fyrir mig um CPU. Spyrja spurninga. Í næsta hluta mun ég tala um vinnsluminni.
gagnlegir krækjur
Heimild: www.habr.com