A teljesítmény elemzése a VMware vSphere virtuális gépeiben. 1. rész: CPU

Ha VMware vSphere (vagy bármely más technológiai stack) alapú virtuális infrastruktúrát adminisztrálsz, akkor valószínűleg gyakran hallod a felhasználóktól a panaszokat: „A virtuális gép lassan működik!”. Ebben a ciklusban megvizsgálom a teljesítménymutatókat, hogy mitől és miért „lassul” a gép, és hogyan érhetjük el, hogy ne „lassuljon”.

A virtuális gépek teljesítményének következő aspektusait fogom megvizsgálni:

• CPU,
• RAM,
• DISK,
• Hálózat.

A CPU-val kezdem.

A teljesítmény elemzéséhez szükségünk lesz:

• vCenter Teljesítménymérők – teljesítménymérők, amelyek grafikonjait a vSphere Clienten keresztül tekinthetjük meg. Az ezekre vonatkozó információk bármely kliens verzióban elérhetők (a „vastag” kliens C#-ban, web kliens Flexen és web kliens HTML5-ben). Ezekben a cikkekben a C#-klienből készült képernyőfotókat fogjuk használni, csak azért, mert jobban mutatnak a miniatűrön :)
• ESXTOP – egy eszköz, amelyet az ESXi parancssorából indítanak. Ezzel valós időben kaphatunk teljesítménymérő értékeket, vagy ezeket egy adott időszak alatt .csv fájlba exportálhatjuk további elemzés céljából. Később részletesebben mesélek erről az eszközről, és néhány hasznos linket is megosztok a dokumentációról és a témával kapcsolatos cikkekről.

Egy kis elmélet

Az ESXi-ben minden vCPU (a virtuális gép magja) működéséért egy külön folyamat felelős - világ a VMware terminológia szerint. Vannak szolgáltató folyamatok is, de a virtuális gép teljesítményének elemzése szempontjából ezek kevésbé érdekesek.

A folyamat az ESXi-ben négy állapotban lehet:

• Run – a folyamat valamilyen hasznos munkát végez.
• Várakozás – a folyamat nem végez munkát (inaktív), vagy bemeneti/kimeneti műveletre vár.
• Költségstop – olyan állapot, amely többmagos virtuális gépeknél lép fel. Akkor fordul elő, amikor a hypervisor CPU ütemezője (ESXi CPU Scheduler) nem tudja ütemezni a virtuális gép összes aktív magjának egyidejű végrehajtását a fizikai szerver magjain. A fizikai világban minden processzormag párhuzamosan működik, a vendég operációs rendszer pedig a virtuális gépben hasonló viselkedésre számít, így a hypervisornak le kell lassítania azokat a virtuális gép magokat, amelyek gyorsabban tudják befejezni a ciklust. Az ESXi modern verzióiban a CPU ütemező egy olyan mechanizmust használ, amelyet relaxált együttes ütemezésnek neveznek: a hypervisor figyelembe veszi a virtuális gép „leggyorsabb” és „leglassúbb” magja közötti eltérést (skew). Ha az eltérés egy bizonyos küszöböt meghalad, a „gyors” mag kosztop állapotba kerül. Ha a virtuális gép magjai sok időt töltenek ebben az állapotban, az teljesítményproblémákhoz vezethet.
• Kész – a folyamat ebbe az állapotba lép, amikor a hypervisor nem tud erőforrásokat biztosítani a végrehajtásához. A magas ready értékek teljesítményproblémákat okozhatnak a virtuális gép számára.

A virtuális gép CPU teljesítménymérő fő számlálói

CPU használat, %. Megmutatja a CPU használatának százalékos arányát egy adott időszak alatt.

Hogyan elemezzük? Ha a virtuálisgép folyamatosan 90%-os CPU-t használ vagy 100%-os csúcsokat mutat, akkor problémáink vannak. A problémák nemcsak a virtuális gépen belüli alkalmazások „lassú” működésében, hanem a virtuális gép hálózati elérhetetlenségében is megnyilvánulhatnak. Ha a monitoring rendszere azt mutatja, hogy a virtuális gép időszakosan leáll, figyeljen a CPU használat grafikonjain megjelenő csúcsokra.

Van egy standard riasztás, amely megjeleníti a virtuális gép CPU terhelését:

Mit tegyünk? Ha a virtuális gép CPU használata folyamatosan a határérték felett van, érdemes megfontolni a vCPU számának növelését (sajnos ez nem mindig segít) vagy a virtuális gép átköltöztetését egy erősebb processzorral rendelkező szerverre.

CPU használat Mhz-ben

A vCenter grafikonokon a használat % -ban csak az egész virtuális gépre vonatkozóan nézhető meg, egyes magok grafikonai nincsenek (az Esxtop értékek % -ban a magok szerint megvannak). Minden egyes magra külön meg lehet nézni a használatot MHz-ben.

Hogyan elemezzük? Előfordul, hogy az alkalmazás nincs optimalizálva a többmagos architektúrára: csak az egyik magot használja 100%-osan, míg a többi terheletlenül marad. Például az MS SQL alapértelmezett biztonsági mentési beállításaival csak egy magon indítja a folyamatot. Ennek eredményeként a biztonsági mentés lassulása nem a lemez sebességének köszönhető (ez volt az, amire a felhasználó eleinte panaszkodott), hanem mert a processzor nem bírja a terhet. A probléma megoldható a paraméterek megváltoztatásával: a biztonsági mentések párhuzamosan több fájlban (így több folyamatban) indultak.

A magok egyenlőtlen terhelésének példája.

Előfordul olyan helyzet is (ahogyan a fenti grafikonon látható), amikor a magok egyenlőtlenül vannak terhelve, és néhányukon 100%-os csúcsok figyelhetők meg. Akárcsak egyetlen mag terhelésénél, a CPU használat alarm nem fog működni (ez az egész VM-re vonatkozik), de teljesítményproblémák lépnek fel.

Mit tegyünk? Ha a VM-ben futó szoftver egyenlőtlenül terheli a magokat (csak egy magot vagy a magok egy részét használja), nincs értelme a magok számának növelésének. Ilyen esetben jobb, ha a VM-et egy teljesítményben erősebb processzorral rendelkező szerverre helyezzük át.

Érdemes lehet ellenőrizni a szerver BIOS-a energiatakarékossági beállításait is. Sokan a BIOS-ban a Nagy Teljesítmény módot választják, ezzel letiltva a C-state és P-state energiatakarékos technológiákat. A modern Intel processzorokban alkalmazott Turbo Boost technológia az egyes processzormagok órajelének növelésére szolgál más magok rovására. De ez csak akkor működik, ha az energiatakarékos technológiák be vannak kapcsolva. Ha ezeket kikapcsoljuk, a processzor nem tudja csökkenteni az energifogyasztást azoknál a magoknál, amelyek nincsenek terhelve.

A VMware azt javasolja, hogy ne kapcsoljuk ki az energiatakarékos technológiákat a szervereken, hanem olyan beállításokat válasszunk, amelyek maximálisan a hipervizorra bízzák az energiamenedzsmentet. Ilyen esetben a hipervizor energiatakarékossági beállításainál a Nagy Teljesítmény módot kell választani.

Ha az infrastruktúrában külön VM-ek (vagy a VM-ek magjai) magasabb CPU frekvenciát igényelnek, az energiatakarékosság helyes beállítása jelentősen javíthatja a teljesítményüket.

CPU Ready (Készség)

Ha a VM magja (vCPU) Ready állapotban van, akkor nem végez hasznos munkát. Ez az állapot akkor fordul elő, amikor a hypervisor nem talál szabad fizikai magot, amelyre a VM vCPU folyamatot rá lehetne bízni.

Hogyan elemezzük? Általában, ha a virtuális gép magjai több mint 10% időt Ready állapotban vannak, akkor teljesítményproblémákat fog észlelni. Egyszerűbben fogalmazva, a VM több mint 10% időt tölt azzal, hogy várja a fizikai erőforrások elérhetőségét.

A vCenterben megtekinthető két mutató, amelyek a CPU Ready-hez kapcsolódnak:

• Readiness,
• Ready.

Mindkét mutató értéke megtekinthető a teljes VM-en, valamint az egyes magokon is.
A Readiness mutató azonnal százalékos értéket jelez, de csak valós időben (az utolsó órára vonatkozó adatok, 20 másodperces mérési intervallumban). Ezt a mutatót inkább csak a 'forró nyom' problémák keresésére érdemes használni.

A Ready mutató értéke történeti perspektívából is megtekinthető. Ez hasznos az összefüggések megállapításához és a probléma mélyebb elemzéséhez. Például, ha a virtuális gép teljesítményproblémákba ütközik egy adott időpontban, akkor az emelkedett CPU Ready érték intervallumait össze lehet hasonlítani a szerver általános terhelésével, ahol a VM működik, és intézkedéseket lehet tenni a terhelés csökkentésére (ha a DRS nem boldogult).

A Ready, a Readiness-től eltérően, nem százalékokban, hanem milliszekundumban jelenik meg. Ez egy Summation típusú mutató, azaz azt mutatja, hogy a VM mag mennyi időt töltött Ready állapotban a mérési időszak alatt. Az értéket egy egyszerű képlettel át lehet számítani százalékokba:

(CPU ready summation value / (chart default update interval in seconds * 1000)) * 100 = CPU ready %

Például egy az alábbi grafikonon a virtuális gép teljes Ready csúcsértéke a következő lesz:

A Ready százalékának számításakor érdemes figyelembe venni két dolgot:

• A teljes VM Ready értéke a magok Ready értékeinek összege.
• A mérési intervallum. Valós időben ez 20 másodperc, például a napi grafikonok esetében 300 másodperc.

Aktív hibakeresés során ezeket az egyszerű pillanatokat könnyen el lehet mulasztani, és értékes időt lehet pazarolni nem létező problémák megoldására.

A Ready értéket az alábbi diagram adatai alapján számítjuk ki. (324474/(20*1000))*100 = 1622% az egész VM-re. Ha a magokra nézünk, már nem tűnik annyira ijesztőnek: 1622/64 = 25% magonként. Ebben az esetben a csapda felfedezése meglehetősen egyszerű: a Ready érték irreális. De ha 10-20% van az egész VM-re több mag esetén, akkor minden mag esetében az érték a normál tartományban lehet.

Mit tegyünk? A magas Ready érték azt jelzi, hogy a szervernek nincs elegendő CPU erőforrása a virtuális gépek normális működéséhez. Ilyen helyzetben csak a CPU túlterhelés csökkentése (vCPU:pCPU) marad. Nyilvánvaló, hogy ezt a meglévő VM paramétereinek csökkentésével vagy egyes VM-ek migrálásával más szerverekre lehet elérni.

Co-stop

Hogyan elemezzük? Ez a számláló szintén Summation típusú, és hasonlóan a Ready-hoz, százalékokra konvertálható:

(CPU co-stop summation value / (diagram alapértelmezett frissítési intervalluma másodpercben * 1000)) * 100 = CPU co-stop %

Itt is figyelni kell a VM magjainak számára és a mérési intervallumra.
A co-stop állapotban a mag nem végez hasznos munkát. A VM méretének és a szerver terhelésének helyes megválasztásával a co-stop számlálónak közel kell lennie a nullához.

Ebben az esetben a terhelés egyértelműen normális:)

Mit tegyünk? Ha egy hypervisoron több VM működik sok maggal, és van CPU túlterhelés, a co-stop számláló megemelkedhet, ami teljesítményproblémákhoz vezethet a VM-eknél.

A co-stop szintén megemelkedik, ha az aktív VM magok számára szálakat használnak egy fizikailag egy magra telepített szerveren, ami hyper-threading-gel van engedélyezve. Ilyen helyzet léphet fel például, ha a VM-nek több magja van, mint amennyi fizikailag elérhető a szerveren, ahol működik, vagy ha a VM-nél a 'preferHT' beállítás engedélyezve van. Erről a beállításról itt olvashat. itt.

A VM teljesítményproblémáinak elkerülése érdekében a magas co-stop miatt válassza a VM méretét a szoftvergyártó ajánlása szerint, amely ezen a VM-en működik, és figyelembe véve a VM működési helyén található fizikai szerver lehetőségeit.

Ne adjon hozzá magokat tartalékként, ez problémákat okozhat a VM teljesítményében, valamint a szerveren található szomszédai számára is.

Egyéb hasznos CPU metrikák

Run – hány időt (ms) töltött a vCPU a mérési időszak alatt RUN állapotban, tehát ténylegesen végezte a hasznos munkát.

Idle – mennyi idő (ms) alatt volt a vCPU tétlen állapotban a mérési időszak alatt. A magas Idle értékek nem probléma, egyszerűen a vCPU-nak "nem volt mit tennie".

Várakozás – mennyi idő (ms) alatt volt a vCPU várakozó állapotban a mérési időszak alatt. Mivel az Idle is belekerül ebbe a számlálóba, a magas Wait értékek sem jeleznek problémát. Ha viszont a magas Wait mellett az Idle alacsony, az azt jelenti, hogy a VM az I/O műveletek befejezésére várt, ami problémát jelezhet a merevlemez teljesítményével vagy a VM virtuális eszközeivel kapcsolatban.

Max limitált – mennyi idő (ms) alatt volt a vCPU készenléti állapotban a beállított erőforráskorlátozás miatt. Ha a teljesítmény érthetetlenül alacsony, érdemes ellenőrizni ezt a számlálót és a CPU korlátot a VM beállításaiban. Lehet, hogy a VM-nek van korlátja, amiről nem tudsz. Például ez történik, amikor a VM egy sablonból lett klónozva, ahol a CPU korlát be volt állítva.

Swap várakozás – mennyi időt várt a vCPU a VMkernel Swap műveletére a mérési időszak alatt. Ha ennek a számlálnak az értéke nulla felett van, akkor a VM-nek biztosan vannak teljesítményproblémái. Részletesen a SWAP-ról a RAM számlálókkal foglalkozó cikkben beszélünk.

ESXTOP

Ha a vCenter teljesítményszámlálói jók a történeti adatok elemzésére, akkor a problémák operatív elemzéséhez a legjobb az ESXTOP. Itt minden érték készen áll (nem kell semmit lefordítani), és a minimális mérési időszak 2 másodperc.
Az ESXTOP CPU képernyő a 'c' gomb megnyomásával hívható elő, és a következőképpen néz ki:

A kényelem érdekében hagyja csak a virtuális gépek folyamatait, a Shift-V megnyomásával.
A VM különböző magjainak metrikáinak megtekintéséhez nyomja meg az 'e' gombot, és írja be az érdeklődő VM GID-t (30919 a lenti képernyőképen):

Röviden áttekintem az alapértelmezés szerint megjelenő oszlopokat. További oszlopok hozzáadhatók az 'f' gomb megnyomásával.

NWLD (Világok Száma) – a csoportban lévő folyamatok száma. A csoport kibővítéséhez és az egyes folyamatok (például a többmagos VM esetén minden mag) metrikáinak megtekintéséhez nyomja meg az “e” gombot. Ha a csoportban több mint egy folyamat van, akkor a csoport metrikáinak értéke az egyes folyamatok metrikáinak összegével egyenlő.

%HASZNÁLT – mennyi CPU ciklust használ a szerver egy folyamat vagy folyamatcsoport.

%FUT – mennyi időt töltött a folyamat RUN állapotban a mérési időszak során, azaz végzett hasznos munkát. Különbözik a %USED-től, mert nem veszi figyelembe a hyper-threadinget, a frekvencia skálázást és a rendszerfeladatokra (%SYS) fordított időt.

%SYS – az idő, amelyet rendszerfeladatokra fordítottunk, például megszakítások kezelésére, bemenetre/kimenetre, hálózati munkára stb. Az érték magas lehet, ha a VM-nek nagymértékű bemenete/kimenete van.

%OVRLP – mennyi időt töltött a fizikai mag, amelyen a VM folyamat fut, más folyamatok feladataira.

Ezek a metrikák egymással a következőképpen viszonyulnak:

%USED = %RUN + %SYS – %OVRLP.

Általában a %USED metrika informatívabb.

%WAIT – mennyi időt töltött a folyamat a mérési időszak során Wait állapotban. Tartalmazza az IDLE-t is.

%IDLE – mennyi időt töltött a folyamat a mérési időszak során IDLE állapotban.

%SWPWT – mennyi időt töltött a mérési időszak során az vCPU a VMkernel Swap műveletre várva.

%VMWAIT – mennyi időt töltött a mérési időszak során az vCPU események (általában bemenetre/kimenetre) várakozva. Ezen metrikának nincs megfelelője a vCenterben. A magas értékek problémákat jeleznek a VM bemeneti/kimeneti teljesítményével kapcsolatban.

%WAIT = %VMWAIT + %IDLE + %SWPWT.

Ha a VM nem használ VMkernel Swap-ot, akkor a teljesítményproblémák elemzésekor érdemes figyelembe venni a %VMWAIT-t, mivel ez a metrika nem számolja azt az időt, amikor a VM semmit sem csinált (%IDLE).

%RDY – mennyi időt töltött a folyamat a mérési időszak során Ready állapotban.

%CSTP – mennyi időt töltött a folyamat a mérési időszak során costop állapotban.

%MLMTD – mennyi időt töltött az vCPU a mérési időszak során Ready állapotban a beállított erőforráslimitek miatt.

%WAIT + %RDY + %CSTP + %RUN = 100% – a VM magja mindig ezekben a négy állapotban van.

CPU a hipervizoron

A vCenterben van CPU teljesítménymérő a hipervizor számára is, de ezek nem érdekesek – ez egyszerűen a szerveren lévő összes VM teljesítménymérőinek összege.
A legkényelmesebb CPU állapotát a szerveren a Summary fülem alatt ellenőrizni:

A szerver számára, akárcsak a virtuális gép számára, létezik egy alapértelmezett riasztás:

Magas CPU terhelés esetén a szerveren futó VM-ek teljesítményproblémákat tapasztalnak.

Az ESXTOP-on a szerver CPU terhelésének adatai a képernyő tetején találhatók. A standard CPU terhelés mellett, amely a hypervisorok számára nem túl informatív, három további mutató is van:

CORE UTIL(%) – a fizikai szerver magjának terhelése. Ez a számláló azt mutatja, mennyi időt dolgozott a mag a mérési időszak alatt.

PCPU UTIL(%) – ha a hyper-threading be van kapcsolva, akkor minden fizikai magra két szál (PCPU) jut. Ez a mutató azt mutatja, mennyi időt dolgozott mindegyik szál.

PCPU USED(%) – ugyanaz, mint a PCPU UTIL(%), de figyelembe veszi a frequency scaling-et (a mag frekvenciájának csökkentése energia megtakarítás céljából, vagy a Turbo Boost technológia révén történő növelése) és a hyper-threading-et.

PCPU_USED% = PCPU_UTIL% * effektív magfrekvencia / névleges magfrekvencia.

Ezen a képernyőképen néhány mag számára a Turbo Boost működése miatt a USED érték 100%-nál magasabb, mivel a mag frekvenciája a névlegesnél magasabb.

Néhány szó a hyper-threading figyelembevételéről. Ha a folyamatok 100% időt töltöttek a fizikai mag mindkét szálán, és a mag a névleges frekvencián működik, akkor:

• A CORE UTIL a mag számára 100% lesz,
• A PCPU UTIL mindkét szál számára 100% lesz,
• A PCPU USED mindkét szál számára 50% lesz.

Ha mindkét szál nem dolgozott a mérési időszak 100%-ában, akkor azokban az időszakokban, amikor a szálak párhuzamosan működtek, a PCPU USED a magok számára feleződik.

Az ESXTOP-on van egy képernyő a szerver CPU energiafogyasztási paramétereivel. Itt meg lehet nézni, hogy a szerver használja-e az energiahatékonysági technológiákat: C-states és P-states. Az 'p' billentyű lenyomásával hívható elő:

CPU teljesítménylehetőségek szokásos problémái

Végül átírok néhány tipikus okot a VM CPU teljesítményének problémáira, és adok rá rövid megoldási javaslatokat:

Nem elegendő a mag órajel. Ha nincs lehetőség a VM-t erősebb magokra áthelyezni, próbálja meg módosítani az energiafogyasztási beállításokat, hogy a Turbo Boost hatékonyabb legyen.

Hibás VM méretezés (túl sok/túl kevés mag). Ha túl kevés magot állít be, magas CPU terhelést tapasztalhat a VM-en. Ha túl sok, magas co-stop valószínű.

Magas CPU túlbérlés a szerveren. Ha a VM-en magas Ready-n van, csökkentse a CPU túlbérlést.

Hibás NUMA-topológia nagyobb VM-ek esetén. A VM's NUMA topology (vNUMA) must match the server's NUMA topology (pNUMA). Diagnostics and possible solutions to this problem are discussed, for example, in the book «VMware vSphere 6.5 Host Resources Deep Dive». If you don't want to dive deep and have no licensing restrictions on the OS installed on the VM, create multiple virtual sockets with one core each on the VM. You won't lose much 🙂

That's all I have on CPU. Feel free to ask questions. In the next part, I'll talk about RAM.

Hasznos linkekhttp://virtual-red-dot.info/vm-cpu-counters-vsphere/
https://kb.vmware.com/kb/1017926
http://www.yellow-bricks.com/2012/07/17/why-is-wait-so-high/
https://communities.vmware.com/docs/DOC-9279
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/whats-new-vsphere65-perf.pdf
https://pages.rubrik.com/host-resources-deep-dive_request.html

Forrás: habr.com