Ha egy VMware vSphere (vagy bármely más technológiai verem) alapú virtuális infrastruktúrát adminisztrál, valószínűleg gyakran hallani panaszokat a felhasználóktól: „A virtuális gép lassú!” Ebben a cikksorozatban a teljesítménymutatókat elemzem, és elmondom, mi és miért lassul le, és hogyan biztosítható, hogy ne lassuljon.
A virtuális gép teljesítményének következő szempontjait veszem figyelembe:
- CPU,
- RAM,
- KORONG,
- Hálózat.
Kezdem a CPU-val.
A teljesítmény elemzéséhez a következőkre lesz szükségünk:
- vCenter teljesítményszámlálók – teljesítményszámlálók, amelyek grafikonjait a vSphere Clienten keresztül lehet megtekinteni. Ezekre a számlálókra vonatkozó információk elérhetők a kliens bármely verziójában (C#-ban „vastag” kliens, Flex-ben webkliens és HTML5-ben webkliens). Ezekben a cikkekben a C# kliens képernyőképeit fogjuk használni, csak azért, mert miniatűrben jobban néznek ki :)
- ESXTOP – egy segédprogram, amely az ESXi parancssorból fut. Segítségével valós időben kaphatja meg a teljesítményszámlálók értékeit, vagy egy bizonyos időszakra feltöltheti ezeket az értékeket egy .csv fájlba további elemzés céljából. Ezután többet mondok el erről az eszközről, és számos hasznos linket biztosítok a témával kapcsolatos dokumentációhoz és cikkekhez.
Egy kis elmélet
Az ESXi-ben minden egyes vCPU (virtuális gépmag) működéséért egy külön folyamat – a VMware terminológiájában világ – felel. Vannak szolgáltatási folyamatok is, de a VM teljesítményének elemzése szempontjából ezek kevésbé érdekesek.
Az ESXi egyik folyamata négy állapot egyikében lehet:
- futás – a folyamat hasznos munkát végez.
- Várjon – a folyamat nem végez munkát (tétlen), vagy bemenetre/kimenetre vár.
- Costop – többmagos virtuális gépekben előforduló állapot. Ez akkor fordul elő, ha a hypervisor CPU ütemező (ESXi CPU Scheduler) nem tudja ütemezni az összes aktív virtuális gép mag egyidejű végrehajtását a fizikai kiszolgálómagokon. A fizikai világban minden processzormag párhuzamosan működik, a VM-en belüli vendég operációs rendszer hasonló viselkedést vár el, így a hypervisornak le kell lassítania azokat a VM magokat, amelyek képesek gyorsabban befejezni az órajelet. Az ESXi modern verzióiban a CPU-ütemező egy laza együttütemezésnek nevezett mechanizmust használ: a hypervisor figyelembe veszi a „leggyorsabb” és a „leglassabb” virtuális gépmag közötti különbséget (ferdítés). Ha a rés meghalad egy bizonyos küszöböt, akkor a gyors mag átkerül a költségtartó állapotba. Ha a virtuálisgép-magok sok időt töltenek ebben az állapotban, az teljesítményproblémákat okozhat.
- Kész – a folyamat akkor kerül ebbe az állapotba, ha a hypervisor nem tud erőforrásokat lefoglalni a végrehajtásához. A magas készenléti értékek virtuális gép teljesítményproblémákat okozhatnak.
Alapvető virtuális gép CPU teljesítményszámlálók
CPU-használat, %. A CPU-használat százalékos arányát mutatja egy adott időszakban.
Hogyan kell elemezni? Ha egy virtuális gép folyamatosan 90%-on használja a CPU-t, vagy 100%-ig vannak csúcsok, akkor problémáink vannak. A problémák nemcsak az alkalmazás VM-en belüli „lassú” működésében, hanem a virtuális gép hálózaton keresztüli elérhetetlenségében is kifejeződhetnek. Ha a megfigyelő rendszer azt mutatja, hogy a virtuális gép időnként leesik, figyeljen a CPU-használati grafikon csúcsaira.
Van egy szabványos riasztás, amely a virtuális gép CPU-terhelését mutatja:
Mit kell tenni? Ha egy virtuális gép CPU-használata folyamatosan tönkremegy, akkor érdemes lehet a vCPU-k számának növelésére gondolni (sajnos ez nem mindig segít), vagy áthelyezni a virtuális gépet egy erősebb processzorral rendelkező szerverre.
CPU használat MHz-ben
A vCenter Usage % grafikonjain csak a teljes virtuális gépet láthatja, az egyes magokra vonatkozóan nincsenek grafikonok (az Esxtopban a magok %-os értékei vannak). Az egyes magoknál a Használat MHz-ben látható.
Hogyan kell elemezni? Előfordul, hogy egy alkalmazás nincs többmagos architektúrára optimalizálva: csak egy magot használ 100%-ban, a többi terhelés nélkül tétlen. Például az alapértelmezett biztonsági mentési beállításokkal az MS SQL csak egy magon indítja el a folyamatot. Emiatt a mentés nem a lemezek lassú sebessége miatt lassul (erre kezdetben a felhasználó panaszkodott), hanem azért, mert a processzor nem tud megbirkózni vele. A problémát a paraméterek megváltoztatásával sikerült megoldani: több fájlban (illetve több folyamatban) párhuzamosan elkezdett futni a mentés.
Példa a magok egyenetlen terhelésére.
Van olyan helyzet is (mint a fenti grafikonon), amikor a magok egyenetlenül vannak terhelve, és némelyikük csúcsa 100%. Csakúgy, mint egy mag betöltésekor, a CPU-használat riasztása nem fog működni (az egész virtuális gépre vonatkozik), de teljesítményproblémák lesznek.
Mit kell tenni? Ha egy virtuális gép szoftvere egyenetlenül tölti be a magokat (csak egy magot vagy a magok egy részét használja), akkor nincs értelme növelni a magokat. Ebben az esetben jobb, ha a virtuális gépet egy erősebb processzorral rendelkező kiszolgálóra helyezi át.
Megpróbálhatja ellenőrizni az energiafogyasztási beállításokat a kiszolgáló BIOS-ában is. Sok rendszergazda engedélyezi a nagy teljesítményű módot a BIOS-ban, és ezzel letiltja a C-states és P-states energiatakarékos technológiákat. A modern Intel processzorok Turbo Boost technológiát használnak, amely növeli az egyes processzormagok frekvenciáját a többi mag rovására. De ez csak akkor működik, ha az energiatakarékos technológiák be vannak kapcsolva. Ha letiltjuk őket, a processzor nem tudja csökkenteni a fel nem töltött magok energiafogyasztását.
A VMware azt javasolja, hogy ne tiltsa le az energiatakarékos technológiákat a szervereken, hanem olyan módokat válasszon, amelyek az energiagazdálkodást lehetőleg a hypervisorra bízzák. Ebben az esetben a hypervisor energiafogyasztási beállításainál ki kell választania a High Performance lehetőséget.
Ha az infrastruktúrájában vannak olyan virtuális gépek (vagy virtuális gépmagok), amelyek megnövelt CPU-frekvenciát igényelnek, az energiafogyasztás helyes beállítása jelentősen javíthatja a teljesítményüket.
CPU kész
Ha a virtuálisgép-mag (vCPU) kész állapotban van, akkor nem végez hasznos munkát. Ez az állapot akkor fordul elő, ha a hypervisor nem talál szabad fizikai magot, amelyhez a virtuális gép vCPU-folyamata hozzárendelhető.
Hogyan kell elemezni? Általában, ha egy virtuális gép magjai az esetek több mint 10%-ában Ready állapotban vannak, teljesítménybeli problémákat észlel. Egyszerűen fogalmazva, a virtuális gép az esetek több mint 10%-ában arra vár, hogy a fizikai erőforrások elérhetővé váljanak.
A vCenterben 2 számlálót tekinthet meg a CPU Ready-hez kapcsolódóan:
- készenlét,
- Kész.
Mindkét számláló értéke megtekinthető mind a teljes virtuális gépre, mind az egyes magokra vonatkozóan.
A Készenlét azonnal százalékban mutatja az értéket, de csak valós időben (az utolsó óra adatai, mérési intervallum 20 másodperc). Jobb, ha ezt a számlálót csak a „homályos” problémák keresésére használja.
A kész számláló értékek történelmi szempontból is megtekinthetők. Ez hasznos minták megállapításához és a probléma mélyebb elemzéséhez. Például, ha egy virtuális gép egy bizonyos időpontban teljesítményproblémákat tapasztal, akkor összehasonlíthatja a CPU Ready érték intervallumait azon a kiszolgáló teljes terhelésével, amelyen ez a virtuális gép fut, és intézkedéseket tehet a terhelés csökkentésére (ha DRS nem sikerül).
A Readiness-től eltérően a készenlét nem százalékban, hanem ezredmásodpercben jelenik meg. Ez egy Summation típusú számláló, vagyis azt mutatja meg, hogy a mérési periódus alatt mennyi ideig volt a VM mag Ready állapotban. Ezt az értéket százalékra konvertálhatja egy egyszerű képlettel:
(CPU készenléti összegzési érték / (a diagram alapértelmezett frissítési időköze másodpercben * 1000)) * 100 = CPU készenléti %
Például az alábbi grafikonon látható virtuális gép esetében a teljes virtuális gépre vonatkozó Ready csúcsérték a következő lesz:
A készenléti százalék kiszámításakor két pontra kell figyelni:
- A teljes virtuális gép Ready értéke a készenléti értékek összege a magok között.
- Mérési intervallum. Valós idejű esetén 20 másodperc, és például a napi grafikonokon 300 másodperc.
Az aktív hibaelhárítással ezek az egyszerű pontok könnyen kimaradhatnak, és értékes időt veszíthetünk el nem létező problémák megoldására.
Számítsuk ki a Ready-t az alábbi grafikon adatai alapján. (324474/(20*1000))*100 = 1622% a teljes virtuális gépre. Ha a magokat nézzük, nem olyan ijesztő: 1622/64 = 25% magonként. Ebben az esetben a fogást meglehetősen könnyű észrevenni: a Ready érték irreális. De ha 10-20%-ról beszélünk a több magos teljes virtuális gépre, akkor minden mag esetében az érték a normál tartományon belül lehet.
Mit kell tenni? A magas Ready érték azt jelzi, hogy a kiszolgáló nem rendelkezik elegendő processzorerőforrással a virtuális gépek normál működéséhez. Ilyen helyzetben nem marad más hátra, mint a processzoronkénti túljelentkezés (vCPU:pCPU) csökkentése. Nyilvánvalóan ez elérhető a meglévő virtuális gépek paramétereinek csökkentésével vagy a virtuális gépek egy részének más szerverekre való migrálásával.
Co-stop
Hogyan kell elemezni? Ez a számláló is Összegzés típusú, és ugyanúgy százalékosra konvertálható, mint a Ready:
(CPU ko-stop összegzési értéke / (a diagram alapértelmezett frissítési időköze másodpercben * 1000)) * 100 = CPU együttállás %
Itt is figyelni kell a VM-en lévő magok számára és a mérési intervallumra.
Costop állapotban a kernel nem végez hasznos munkát. A virtuális gép méretének megfelelő kiválasztása és a kiszolgáló normál terhelése esetén a co-stop számlálónak nullához közel kell lennie.
Ebben az esetben a terhelés egyértelműen abnormális :)
Mit kell tenni? Ha több, nagyszámú maggal rendelkező virtuális gép fut egy hypervisoron, és túljelentkezés van a CPU-n, akkor a co-stop számláló megnőhet, ami problémákat okozhat ezen virtuális gépek teljesítményében.
Ezenkívül az együttállás növekszik, ha egy virtuális gép aktív magjai egy fizikai szervermagon lévő szálakat használnak, és engedélyezve van a hiper-treading. Ez a helyzet például akkor fordulhat elő, ha a virtuális gép több maggal rendelkezik, mint amennyi fizikailag elérhető azon a kiszolgálón, amelyen fut, vagy ha a „preferHT” beállítás engedélyezve van a virtuális gépen. Erről a beállításról olvashat .
A virtuális gép teljesítményével kapcsolatos, a magas együttállás miatti problémák elkerülése érdekében válassza ki a virtuális gép méretét az ezen a virtuális gépen futó szoftver gyártójának ajánlásaival és a virtuális gépet futtató fizikai kiszolgáló képességeivel összhangban.
Ne adjon hozzá magokat tartalékba; ez nem csak magának a virtuális gépnek, hanem a kiszolgálón lévő szomszédainak is teljesítményproblémákat okozhat.
Egyéb hasznos CPU-metrikák
futás – mennyi ideig (ms) a mérési időszak alatt a vCPU RUN állapotban volt, azaz ténylegesen hasznos munkát végzett.
Idle – mennyi ideig (ms) volt a vCPU inaktív állapotban a mérési időszak alatt. A magas üresjárati értékek nem jelentenek problémát, a vCPU-nak egyszerűen „semmi dolga”.
Várjon – mennyi ideig (ms) volt a mérési periódus alatt a vCPU Várakozás állapotban. Mivel az IDLE benne van ebben a számlálóban, a magas várakozási értékek sem jelentenek problémát. De ha a Wait IDLE alacsony, amikor a Wait magas, az azt jelenti, hogy a virtuális gép az I/O műveletek befejezésére várt, és ez viszont a merevlemez vagy a virtuális gép bármely virtuális eszközének teljesítményével kapcsolatos problémát jelezhet.
Max korlátozott – mennyi ideig (ms) volt a vCPU a mérési időszak alatt Ready állapotban a beállított erőforráskorlát miatt. Ha a teljesítmény megmagyarázhatatlanul alacsony, akkor érdemes ellenőrizni ennek a számlálónak az értékét és a CPU-korlátot a virtuális gép beállításaiban. A virtuális gépeknek valóban lehetnek olyan korlátai, amelyekről Ön nem tud. Ez például akkor fordul elő, ha egy virtuális gépet olyan sablonból klónoztak, amelyen a CPU-korlát be van állítva.
Csere várakozás – a mérési időszak alatt mennyi ideig várt a vCPU a VMkernel Swap műveletre. Ha ennek a számlálónak az értékei nulla felett vannak, akkor a virtuális gépnek határozottan teljesítményproblémái vannak. A SWAP-ról bővebben a RAM-számlálókról szóló cikkben fogunk beszélni.
ESXTOP
Ha a vCenter teljesítményszámlálói alkalmasak az előzményadatok elemzésére, akkor a probléma operatív elemzése jobb az ESXTOP-ban. Itt minden érték kész formában jelenik meg (nem kell semmit lefordítani), és a minimális mérési idő 2 másodperc.
A CPU ESXTOP képernyőjét a "c" billentyűvel hívják elő, és így néz ki:
A kényelem érdekében a Shift-V billentyűkombináció megnyomásával csak virtuális gépi folyamatokat hagyhat ki.
Az egyes virtuálisgép-magok metrikáinak megtekintéséhez nyomja meg az „e” billentyűt, és adja meg a kívánt virtuális gép GID-jét (30919 az alábbi képernyőképen):
Hadd menjek át röviden az alapértelmezés szerint megjelenített oszlopokon. További oszlopok hozzáadhatók az "f" gomb megnyomásával.
NWLD (világok száma) – folyamatok száma a csoportban. A csoport kibontásához és az egyes folyamatokhoz (például egy többmagos virtuális gép minden magjához) tartozó metrikák megtekintéséhez nyomja meg az „e” billentyűt. Ha egy csoportban egynél több folyamat van, akkor a csoporthoz tartozó metrikaértékek megegyeznek az egyes folyamatok metrikáinak összegével.
%HASZNÁLT – hány szerver CPU ciklust használ egy folyamat vagy folyamatcsoport.
%FUSS – a mérési időszakban mennyi ideig volt RUN állapotban a folyamat, azaz. hasznos munkát végzett. Abban különbözik a %USED-től, hogy nem veszi figyelembe a hiperszálakat, a frekvenciaskálázást és a rendszerfeladatokra fordított időt (%SYS).
%SYS – rendszerfeladatokra fordított idő, például: megszakítások feldolgozása, I/O, hálózati működés stb. Az érték magas lehet, ha a virtuális gép nagy I/O-val rendelkezik.
%OVRLP – mennyi időt töltött más folyamatok feladataival az a fizikai mag, amelyen a virtuálisgép-folyamat fut.
Ezek a mutatók a következőképpen kapcsolódnak egymáshoz:
%USED = %RUN + %SYS - %OVRLP.
Általában a %USED mérőszám informatívabb.
%VÁRJON – mennyi ideig volt a folyamat a mérési időszakban Várakozás állapotban. Az IDLE engedélyezése.
%TÉTLEN – mennyi ideig volt a folyamat tétlen állapotban a mérési időszakban.
%SWPWT – a mérési időszak alatt mennyi ideig várt a vCPU a VMkernel Swap műveletre.
%VMWAIT – mennyi ideig volt a vCPU a mérési időszak alatt eseményre váró állapotban (általában I/O). A vCenterben nincs hasonló számláló. A magas értékek a virtuális gép I/O-jával kapcsolatos problémákat jeleznek.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Ha a virtuális gép nem használja a VMkernel Swap-ot, akkor a teljesítményproblémák elemzésekor ajánlatos a %VMWAIT elemet nézni, mivel ez a mérőszám nem veszi figyelembe azt az időt, amikor a virtuális gép nem csinált semmit (%IDLE).
%RDY – a mérési időszak alatt mennyi ideig volt a folyamat Kész állapotban.
%CSTP – a mérési időszak alatt mennyi ideig volt költséges állapotban a folyamat.
%MLMTD – mennyi ideig volt a vCPU a mérési időszak alatt Ready állapotban a beállított erőforráskorlát miatt.
%WAIT + %RDY + %CSTP + %RUN = 100% – a virtuálisgép-mag mindig e négy állapot valamelyikében van.
CPU a hypervisoron
A vCenter CPU-teljesítmény-számlálókat is tartalmaz a hypervisorhoz, de ezek nem érdekesek – egyszerűen a kiszolgálón lévő összes virtuális gép számlálóinak összege.
A CPU állapotát a szerveren a legkényelmesebben az Összegzés lapon tekintheti meg:
A szerverhez és a virtuális géphez is létezik egy szabványos riasztás:
Ha a kiszolgáló CPU-terhelése magas, a rajta futó virtuális gépek teljesítményproblémákat tapasztalnak.
Az ESXTOP-ban a szerver CPU terhelési adatai a képernyő tetején jelennek meg. A normál CPU-terhelésen kívül, amely nem túl informatív a hipervizorok számára, van még három mérőszám:
CORE UTIL (%) – a fizikai szervermag betöltése. Ez a számláló megmutatja, hogy a mag mennyi ideig végzett munkát a mérési időszak alatt.
PCPU UTIL (%) – ha a hiperszálas funkció engedélyezve van, akkor fizikai magonként két szál (PCPU) van. Ez a mérőszám megmutatja, hogy az egyes szálak mennyi ideig tartottak a munka befejezéséhez.
PCPU HASZNÁLT (%) – ugyanaz, mint a PCPU UTIL(%), de figyelembe veszi a frekvenciaskálázást (vagy energiatakarékossági célból csökkenti a magfrekvenciát, vagy növeli a magfrekvenciát a Turbo Boost technológia miatt) és a hiperszálakat.
PCPU_USED% = PCPU_UTIL% * effektív magfrekvencia / névleges magfrekvencia.
Ezen a képernyőképen néhány mag esetében a Turbo Boost miatt a USED érték nagyobb, mint 100%, mivel a magfrekvencia magasabb, mint a névleges.
Néhány szó arról, hogyan veszik figyelembe a hiperszálakat. Ha a folyamatok az idő 100%-ában a szerver fizikai magjának mindkét szálán futnak, miközben a mag a névleges frekvencián működik, akkor:
- A maghoz tartozó CORE UTIL 100% lesz
- A PCPU UTIL mindkét szálnál 100% lesz
- Mindkét szálhoz HASZNÁLT PCPU 50% lesz.
Ha a mérési időszakban mindkét szál nem működött 100%-ban, akkor azokban az időszakokban, amikor a szálak párhuzamosan működtek, a magokhoz HASZNÁLT PCPU-t felezik.
Az ESXTOP-nak van egy képernyője is a szerver CPU energiafogyasztási paramétereivel. Itt láthatja, hogy a szerver használ-e energiatakarékos technológiákat: C-állapotokat és P-állapotokat. A "p" billentyűvel hívható:
Gyakori CPU teljesítménnyel kapcsolatos problémák
Végül áttekintem a VM CPU teljesítményével kapcsolatos problémák tipikus okait, és rövid tippeket adok ezek megoldására:
A mag órajel nem elég. Ha nem lehetséges a virtuális gépet erősebb magokra frissíteni, megpróbálhatja megváltoztatni az energiaellátási beállításokat, hogy a Turbo Boost hatékonyabban működjön.
Helytelen virtuálisgép-méretezés (túl sok/kevés mag). Ha kevés magot telepít, akkor a virtuális gép magas CPU-terheléssel jár. Ha sok van, fogjon egy magas co-stopot.
Nagy CPU túljelentkezés a szerveren. Ha a virtuális gép magas készenléti állapotú, csökkentse a CPU túlfizetését.
Helytelen NUMA topológia nagy virtuális gépeken. A virtuális gép által látott NUMA-topológiának (vNUMA) meg kell egyeznie a kiszolgáló NUMA-topológiájával (pNUMA). A diagnosztika és a probléma lehetséges megoldásai megtalálhatók például a könyvben . Ha nem szeretne mélyebbre menni, és nincsenek licenckorlátozásai a virtuális gépre telepített operációs rendszerre vonatkozóan, hozzon létre sok virtuális socketet a virtuális gépen, egy-egy magot. nem veszítesz sokat :)
Nekem ennyi a CPU-ról. Kérdéseket feltenni. A következő részben a RAM-ról fogok beszélni.
Hasznos Linkek
Forrás: will.com