Ebben a cikkben a vSphere RAM teljesítmény-eliőrmérőinek témájáról fogunk beszélni.
Úgy tűnik, hogy a memória kérdése egyértelműbb, mint a processzor esetében: ha a VM-eknek teljesítményproblémái vannak, azokat nehéz nem észrevenni. Ha viszont felmerülnek, sokkal nehezebb őket kezelni. De mindent sorban.
Egy kis elmélet
A virtuális gépek operatív memóriája a VM-eket futtató szerver memóriájából származik. Ez teljesen nyilvánvaló:). Ha a szerver operatív memóriája nem elegendő minden igényléshez, az ESXi optimalizálási technikákat alkalmaz (memory reclamation techniques). Máskülönben a VM operációs rendszerei memóriahozzáférési hibákkal összeomlanának.
Az ESXi a memória terheltsége alapján dönt arról, hogy milyen technikákat alkalmaz:
Memória állapota
Határérték
Műveletek
Magas
400% a minFree-ből
Miután elérte a felső határt, a nagy memóriaoldalak kicsikre oszlanak (a TPS normál módban működik).
Tisztít
100% a minFree-ből
A nagy memóriaoldalak kicsikre oszlanak, a TPS kényszerített módon működik.
Lágy
64% a minFree-ből
TPS + Balloon
Kemény
32% a minFree-ből
TPS + Compress + Swap
Alacsony
16% a minFree-ből
Compress + Swap + Block
A minFree az a memória mennyisége, amely a hypervisor működéséhez szükséges.
ESXi 4.1-ig a minFree alapértelmezés szerint rögzített mennyiség volt — a szerver operatív memóriájának 6%-a (az arány változtatható volt a Mem.MinFreePct opcióval az ESXi-n). Későbbi verziókban a szerverek memória méretének növekedésével a minFree már a gazdagép memória térfogatától függően számítódik, nem pedig rögzített százalékos értékként.
A minFree alapértelmezett értéke a következőképpen számítható:
A minFree számára fenntartott memória százaléka
Memória tartomány
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Megmaradó memória
Például, egy 128 GB RAM-mal rendelkező szerver esetén a MinFree értéke a következő lesz:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
A tényleges érték eltérhet néhány száz MB-tól, ez a szervertől és az RAM-tól függ.
A minFree számára fenntartott memória százaléka
Memória tartomány
Az érték 128 GB-ra vonatkozóan
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Megmaradó memória (100 GB)
1024 MByte
Általában a termelői környezetben csak a High állapot tekinthető normálisnak. Tesztelési és fejlesztési környezetekben a Clear/Soft állapotok elfogadhatók. Ha a gazda gépen maradt szabad memória 64% MinFree alatt van, akkor az azon futó VM-eknél biztosan teljesítményproblémák lépnek fel.
Minden állapotban bizonyos memóriahelyreállító technikák alkalmazandók, kezdve a TPS-től, amely gyakorlatilag nem befolyásolja a VM teljesítményét, egészen a Swapping-ig. Részletesebben mesélek róluk.
Transparent Page Sharing (TPS). A TPS durván fogalmazva a virtuális gépek RAM-oldalainak deduplikálása a szerveren.
Az ESXi az azonos memóriaoldalakat keresi a virtuális gépek között, összehasonlítva és hash-összeg alapján értékelve az oldalakat, és eltávolítja a duplikátumokat, egy és ugyanazon oldalra mutató hivatkozásokkal helyettesítve azokat a szerver fizikai memóriájában. Ennek eredményeként a fizikai memória fogyasztása csökken, és a memóriatúllépés egyes mértékben elérhető jelentős teljesítménycsökkenés nélkül.
Ez a mechanizmus csak 4 KB méretű memóriaoldalakra működik (kis oldalak). A 2 MB méretű oldalakra (nagy oldalak) a hipervizor még csak nem is próbálkozik a deduplikálással: a nagy méretű azonos oldalak megtalálásának esélye nem túl magas.
Alapértelmezés szerint az ESXi nagy oldalakra osztja ki a memóriát. A nagy oldalak kis oldalakra bontása a High állapot küszöbének elérésekor kezdődik, és kényszerített módon történik, amikor a Clear állapotot elérik (lásd a hipervizor állapotainak táblázatát).
Ha szeretné, hogy a TPS ne várjon a gazda memória megtelésére, akkor az ESXi Advanced Options részében az alábbi értéket kell beállítania “Mem.AllocGuestLargePage” 0-ra (alapértelmezetten 1). Így a virtuális gépek számára a nagy memóriához való hozzárendelés le lesz tiltva.
2014 decemberétől minden ESXi verzióban a TPS alapértelmezetten le van tiltva a VM-ek között, mivel felfedeztek egy sebezhetőséget, amely elméletileg lehetővé tette, hogy egy VM hozzáférjen a másik VM memóriájához. Részletek itt. Az TPS sebezhetőségének gyakorlati megvalósításával kapcsolatos információt nem találtam.
A TPS politika az advanced option segítségével kontrollálható “Mem.ShareForceSalting” az ESXi-n:
0 — Inter-VM TPS. A TPS különböző VM-ek oldalaira működik;
1 – TPS az azonos “sched.mem.pshare.salt” értékkel rendelkező VM-ek számára a VMX-ben;
2 (alapértelmezett) – Intra-VM TPS. A TPS a VM-en belüli oldalakra működik.
Határozottan érdemes nagy oldalakat kikapcsolni és aktiválni az Inter-VM TPS-t a tesztkörnyezetekben. Ezt a nagy számú hasonló VM-et tartalmazó környezetekben is használni lehet. Például a VDI környezetekben a fizikai memória megtakarítása elérheti a tucatnyi százalékot.
Memória Balloning. A Balloning már nem olyan ártalmatlan és átlátható technika a VM operációs rendszere számára, mint a TPS. De ha megfelelően alkalmazzák, a Balloning-gal lehet élni és még dolgozni is.
A VMware Tools telepítésekor a VM-re települ egy speciális illesztőprogram, amelyet Balloon Driver-nek (más néven vmmemctl) hívnak. Amikor a hipervizornak kezd fogyni a fizikai memória és átmegy Soft állapotba, az ESXi arra kéri a VM-et, hogy adja vissza a nem használt RAM-ot ezen a Balloon Driver-en keresztül. Az illesztőprogram viszont az operációs rendszer szintjén működik, és tőle kér memória szabad helyet. A hipervizor látja, hogy a fizikai memória mely oldalait foglalta el a Balloon Driver, elveszi a memóriát a virtuális géptől, és visszaadja a gazdagépnek. Az operációs rendszer működésében nem merülnek fel problémák, mert az operációs rendszeren belül a memória a Balloon Driver által van lefoglalva. Alapértelmezés szerint a Balloon Driver akár a VM memória 65%-át is elviheti.
Ha a VM-en nincsenek telepítve a VMware Tools, vagy a Ballooning ki van kapcsolva (nem ajánlom, de van :), a hipervizor azonnal keményebb memóriakezelési technikákhoz folyamodik. Következtetés: Figyelj arra, hogy a VMware Tools a VM-en telepítve legyen.
A Balloon Driver működését az operációs rendszerből a VMware Tools-on keresztül lehet ellenőrizni..
Memória tömörítés. Ez a technika akkor alkalmazható, amikor az ESXi eléri a Hard állapotot. Ahogyan a neve is sugallja, az ESXi megpróbálja összenyomni a 4 KB-os RAM oldalak méretét 2 KB-ra, ezáltal egy kis helyet felszabadítva a szerver fizikai memóriájában. Ez a technika jelentősen megnöveli a VM memóriájának oldalainak eléréséhez szükséges időt, mivel először fel kell bontani az oldalt. Néha nem minden oldalt sikerül összenyomni, és maga a folyamat is időbe telhet. Ezért ez a technika a gyakorlatban nem túl hatékony.
Memória Swap. A Memória Tömörítés rövid fázisa után az ESXi gyakorlatilag elkerülhetetlenné válik (ha a VM-ek nem költöztek más gazdagépekre, vagy nem álltak le) a Swapping-ra. Ha pedig a memória szinte teljesen elfogyott (Low állapot), a hipervizor leállítja a VM-ek látható memória oldalainak kiosztását, ami problémákat okozhat a VM vendégoperációs rendszereiben.
Így működik a Swapping. Amikor a virtuális gép be van kapcsolva, létrejön egy fájl .vswp kiterjesztéssel. A mérete megegyezik a virtuális gép nem fenntartott RAM-jával: ez a különbség a konfigurált és a fenntartott memória között. A Swapping során az ESXi a virtuális gép memóriaoldalait erre a fájlra menti, és elkezdi ezt használni a szerver fizikai memóriája helyett. Természetesen ez a "memória" több renddel lassabb, mint a valódi, még akkor is, ha a .vswp gyors tárolón található.
A Ballooninggal ellentétben, amikor a virtuális géptől elvonják a fel nem használt oldalakat, a Swapping során a lemezre olyan oldalak kerülhetnek, amelyeket az operációs rendszer vagy a virtuális gépben futó alkalmazások aktívan használnak. Ennek következtében a virtuális gép teljesítménye jelentősen csökkenhet, akár meg is fagyna. A virtuális gép formálisan működik, és legalább az operációs rendszeren belül megfelelően le lehet állítani. Ha türelmes vagy 😉
Ha a virtuális gép a Swap-ba került, az egy nem normális állapot, amelyet lehetőség szerint jobb elkerülni.
A virtuális gép memória teljesítményének fő mutatói
Most végre elérkeztünk a lényeghez. A virtuális gép memória állapotának figyelésére az alábbi mutatók állnak rendelkezésre:
Aktív — megmutatja a memória mennyiségét (KByte), amelyhez a virtuális gép hozzáfért az előző mérési időszakban.
Felhasználás — ugyanaz, mint az Aktív, de a virtuális gép konfigurált memória méretének százalékában. A következő képlettel számítják: aktív ÷ virtuális gép konfigurált memória mérete.
A magas Felhasználás és Aktív nem mindig jelenti a virtuális gép teljesítményproblémáit. Ha a virtuális gép agresszívan használja a memóriát (legalábbis hozzáfér újra), az nem azt jelenti, hogy a memória hiányzik. Inkább arra kell nézni, hogy mi történik az operációs rendszerben.
Van egy standard riasztás a memóriahasználat számára a virtuális gépek esetében:
Megosztott — a virtuális gép memória mennyisége, amelyet a TPS segítségével deduplikáltak (a virtuális gépben vagy a virtuális gépek között).
Megadott — a gazdagép fizikai memóriájának mennyisége (KByte), amelyet a virtuális gép kapott. Tartalmazza a Megosztottat is.
Fogyasztott (Megadva — Megosztott) — a gazdagépről elfogyasztott fizikai memória mennyisége (KByte). Nem tartalmazza a Megosztottat.
Ha a virtuális gép memória egy része nem a gazdagép fizikai memóriájából, hanem swap fájlból származik, vagy a memória a Balloon Driver segítségével van elvonva, ezt a mennyiséget nem veszik figyelembe a Megadott és Fogyasztott értékekben.
A magas Granted és Consumed értékek teljesen normálisak. Az operációs rendszer fokozatosan elveszi a memóriát a hypervisortól, és nem adja vissza. Idővel az aktívan működő VM esetében e mutatók értéke közelít a konfigurált memória mennyiségéhez, és ott maradnak.
Nulla — a VM operatív memóriájának (Kb) mennyisége, amely nullákat tartalmaz. Az ilyen memória a hypervisor számára szabadnak számít, és más virtuális gépeknek adható. Miután a vendég OS írt valamit a nullázott memóriába, az átkonvertálódik Consumed státuszra, és onnan már nem tér vissza.
Reserved Overhead — a VM operatív memóriájának (Kb) mennyisége, amelyet a hypervisor tartott fenn a VM működéséhez. Ez egy kis mennyiség, de feltétlenül szükséges a hoston, különben a VM nem indul el.
Balloon — a VM-ből a Balloon Driver segítségével elvett operatív memória (Kb) mennyisége.
Compressed — az a mennyiségű operatív memória (Kb), amelyet sikerült tömöríteni.
Swapped — az a mennyiségű operatív memória (Kb), amely a fizikai memória hiánya miatt a szerverről a lemezre került.
A Balloon és a többi memory reclamation techniques száma nulla.
Így néz ki a grafikon a normálisan működő 150 GB operatív memóriával rendelkező VM számlálóival.
Az alábbi grafikonon a VM-nek nyilvánvaló problémái vannak. A grafikon alatt látható, hogy a VM számára minden fent említett technika felhasználásra került. A Balloon értéke a VM esetében jelentősen nagyobb, mint a Consumed. Valójában a VM inkább halott, mint élő.
ESXTOP
Ahogyan a CPU esetében, ha gyorsan szeretnénk felmérni a helyzetet a hoston és annak dinamikáját 2 másodperces intervallumokban, érdemes az ESXTOP-ot használni.
Az ESXTOP memória képernyője az «m» gomb megnyomásával hívható elő, és a következőképpen néz ki (a B,D,H,J,K,L,O mezőket választották ki):
Számunkra a következő paraméterek lesznek érdekesek:
Mem overcommit avg — a memória túlgesztusának átlagos értéke a hoston 1, 5 és 15 perc alatt. Ha nulla felett van, az ok lehet a helyzet vizsgálatára, de nem mindig jelzi a problémák jelenlétét.
A sorokban PMEM/MB és VMKMEM/MB — a szerver fizikai memóriájáról és a VMkernel számára elérhető memóriáról szóló információ. Érdekes, hogy itt láthatjuk a minfree értékét (MB-ban), a host memória állapotát (a mi esetünkben magas).
A sorban NUMA/MB látható a memória eloszlása a NUMA-csomópontok (socketek) között. Ebben a példában az eloszlás egyenlőtlen, ami alapvetően nem túl kedvező.
Ezután a szerver általános statisztikája következik a memória visszaállítási technikákról:
PSHARE/MB — ez a TPS statisztika;
SWAP/MB — a Swap használati statisztika;
ZIP/MB — a memóriaoldalak tömörítési statisztikája;
MEMCTL/MB — a Balloon Driver használati statisztika.
A különböző VM-ek esetén a következő információk érdekesek lehetnek számunkra. A VM nevének elrejtésével szeretném elkerülni a zavarokat:). Ha az ESXTOP metrikája megegyezik a vSphere számlálóval, a megfelelő számlálót adom meg.
MEMSZ — a VM-re konfigurált memória mérete (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Megadott méret MB-ban.
TCHD — Aktív méret MB-ban.
MCTL? — Telepítve van-e Balloon Driver a VM-en.
MCTLSZ — Balloon méret MB-ban.
MCTLGT — a memória mérete (MB), amelyet az ESXi ki akar vonni a VM-ből a Balloon Driver-en keresztül (Memctl Target).
MCTLMAX — a maximális memória mérete (MB), amelyet az ESXi ki tud vonni a VM-ből a Balloon Driver-en keresztül.
SWCUR — a jelenlegi memória mérete (MB), amelyet a VM a Swap fájlból kapott.
SWGT — az a memória mérete (MB), amelyet az ESXi a VM-nek ad a Swap fájlból (Swap Target).
Az ESXTOP-on keresztül részletesebb információkat is megtekinthetünk a VM NUMA topológiájáról. Ehhez a D,G mezőket kell kiválasztani:
NHN – NUMA csomópontok, ahol a VM elhelyezkedik. Itt azonnal észrevehetők a széles VM-ek, amelyek nem férnek el egy NUMA csomóponton.
NRMEM – hány megabájt memóriát vesz a VM a távoli NUMA csomópontból.
NLMEM – hány megabájt memóriát vesz a VM a helyi NUMA csomópontból.
N%L – a VM memória százaléka a helyi NUMA csomóponton (ha kevesebb, mint 80% — teljesítménybeli problémák léphetnek fel).
Memória a hypervisoron
Ha a hypervisor CPU számlálók általában nem érdekesek, a memóriával kapcsolatos helyzet éppen ellenkező. A magas memóriahasználat a VM-en nem mindig jelez problémát, de a hypervisor magas memóriahasználata éppen ellenkezőleg, a memória kezeléséhez szükséges technikák aktiválását indítja el, ami teljesítménybeli problémákhoz vezet a VM-ek esetében. Figyelemmel kell kísérni a Host Memory Usage riasztásokat, és meg kell akadályozni, hogy a VM Swap-ra kerüljön.
Unswap
Ha a VM Swap-ra került, a teljesítménye jelentősen csökken. A Ballooning és a tömörítés nyomai gyorsan eltűnnek, ha szabad memória áll rendelkezésre a hoszton, de a virtuális gép nem siet visszatérni a Swap-ból a szerver memóriájába.
Az ESXi 6.0 előtt a legmegbízhatóbb és leggyorsabb módja a VM-ek Swap-ból való kihozásának a rendszer újraindítása (pontosabban a konténer leállítása/indítása) volt. Az ESXi 6.0-tól kezdve azonban megjelent egy bár nem teljesen hivatalos, de működő és megbízható mód a VM-ek Swap-ból való kihozására. Egy konferencián sikerült beszélgetnem az egyik VMware mérnökkel, aki a CPU Scheduler-ért felelt. Megerősítette, hogy a módszer teljesen működőképes és biztonságos. A tapasztalataink alapján ezzel kapcsolatban problémát sem tapasztaltunk.
A VM-ek Swap-ból való kihozásához szükséges parancsok Duncan Epping. Nem fogom megismételni a részletes leírást, csak egy példa a használatára. Amint a képernyőfelvételen látható, némi idő elteltével a megadott parancs végrehajtása után a Swap a VM-ből eltűnik.
Tippek az ESXi memória kezeléséhez
Végül néhány tipp, amelyek segíthetnek elkerülni a VM teljesítményproblémáit a memória miatt:
- Ne engedje meg a memória túllépését a termelő klaszterekben. Javasolt mindig ~20-30% szabad memória megtartása a klaszterben, hogy a DRS-nek (és az adminisztrátornak) legyen mozgástere, és a VM migrációk ne menjenek Swap-ba. Ne feledkezzen meg a redundanciáról sem. Kellemetlen, ha egy szerver meghibásodása után a VM-eket HA segítségével újraindítva egyes gépek még Swap-ba is kerülnek.
- Magas konszolidációjú infrastruktúrákban próbálja NE létrehozni a VM-eket több, mint a gazdagép memória felénél. Ez segít a DRS-nek probléma nélkül elosztani a virtuális gépeket a klaszter szerverei között. Ez a szabály természetesen nem univerzális :)
- Figyelje a Host Memory Usage Alarm-ot.
- Ne felejtse el telepíteni a VMware Tools-t a VM-ekre, és ne kapcsolja ki a Ballooning-ot.
- Fontolja meg az Inter-VM TPS engedélyezését és a Large Pages letiltását VDI és tesztkörnyezetekben.
- Ha a VM teljesítményproblémákat tapasztal, ellenőrizze, hogy nem használ-e memória távoli NUMA csomópontból.
- Minél hamarabb hozza ki a VM-et a Swap-ból! Egyéb okok mellett, ha a VM Swap-ban van, a látható okok miatt a tárolórendszer szenved.
Ezen a ponton ennyit a memóriáról. Az alábbiakban cikkek a témában azok számára, akik szeretnék részletesebben megérteni. A következő cikk a tárolásról fog szólni.
Hasznos linkek
Forrás: habr.com
