Ebben a cikkben a véletlen elérésű memória (RAM) teljesítményszámlálóiról fogunk beszélni a vSphere-ben.
Úgy tűnik, hogy a memóriával minden tisztább, mint a processzorral: ha egy virtuális gépen teljesítményproblémák merülnek fel, nehéz ezeket nem észrevenni. De ha megjelennek, sokkal nehezebb kezelni őket. De először a dolgok.
Egy kis elmélet
A virtuális gépek RAM-ja annak a kiszolgálónak a memóriájából származik, amelyen a virtuális gépek futnak. Ez elég egyértelmű :). Ha a szerver RAM-ja nem mindenkinek elegendő, az ESXi memória-visszanyerési technikákat kezd használni. Ellenkező esetben a virtuális gép operációs rendszerei RAM-hozzáférési hibákkal összeomlanak.
Az ESXi a RAM terhelésétől függően dönti el, hogy mely technikákat használja:
Memóriaállapot
A határ
Tevékenység
Magas
A minFree 400%-a
A felső határ elérése után a nagy memórialapok kicsikre osztódnak (a TPS normál módban működik).
Szűrő kikapcsolása
A minFree 100%-a
A nagy memórialapok kicsire oszlanak, a TPS erőltetett.
Puha
A minFree 64%-a
TPS + léggömb
Kemény
A minFree 32%-a
TPS + tömörítés + csere
Elő/Utó
A minFree 16%-a
Tömörítés + csere + blokkolás
A minFree a hypervisor futtatásához szükséges RAM.
Az ESXi 4.1-ig (beleértve) a minFree alapértelmezés szerint javítva volt - a szerver RAM-jának 6%-a (a százalékot az ESXi Mem.MinFreePct opciójával lehetett módosítani). A későbbi verziókban a szerverek memóriájának növekedése miatt a minFree-t a gazdagép memória mennyisége alapján kezdték kiszámítani, nem pedig fix százalékos értékként.
A minFree értéke (alapértelmezett) a következőképpen kerül kiszámításra:
A minFree számára fenntartott memória százalékos aránya
Memória tartomány
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Fennmaradó memória
Például egy 128 GB RAM-mal rendelkező szervernél 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 a szervertől és a RAM-tól függően néhány száz MB-tal eltérhet.
A minFree számára fenntartott memória százalékos aránya
Memória tartomány
128 GB érték
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Fennmaradó memória (100 GB)
1024 MB
A termő állományok esetében jellemzően csak a Magas állapot tekinthető normálisnak. Tesztelési és fejlesztési padonoknál a Clear/Soft állapotok elfogadhatók lehetnek. Ha a gazdagép RAM-ja kevesebb, mint 64% MinFree, akkor a rajta futó virtuális gépek biztosan teljesítményproblémákkal küzdenek.
Mindegyik állapotban bizonyos memória-visszanyerési technikákat használnak, kezdve a TPS-től, amely gyakorlatilag nincs hatással a virtuális gép teljesítményére, a csereig. Majd mesélek róluk bővebben.
Átlátszó oldalmegosztás (TPS). A TPS durván szólva a kiszolgálón lévő virtuális gépek RAM-oldalainak deduplikációja.
Az ESXi megkeresi az azonos virtuális gép RAM-oldalait az oldalak hash-összegének megszámlálásával és összehasonlításával, és eltávolítja az ismétlődő oldalakat, helyettesítve azokat a szerver fizikai memóriájában lévő, ugyanarra az oldalra mutató hivatkozásokkal. Ennek eredményeként csökken a fizikai memóriafelhasználás, és bizonyos memória-túlfizetés érhető el gyakorlatilag teljesítménycsökkenés nélkül.
Ez a mechanizmus csak 4 KB méretű memóriaoldalak (kis oldalak) esetén működik. A hypervisor meg sem próbálja deduplikálni a 2 MB méretű oldalakat (nagy oldalakat): nem nagy az esély, hogy ekkora azonos oldalakat találjon.
Alapértelmezés szerint az ESXi memóriát foglal le a nagy oldalakhoz. A nagy oldalak felosztása kis oldalakra a Magas állapotküszöb elérésekor kezdődik, és a Törlés állapot elérésekor kényszerül (lásd a hypervisor állapottáblázatát).
Ha azt szeretné, hogy a TPS elkezdjen működni anélkül, hogy megvárná, amíg a gazdagép RAM megtelik, be kell állítania az értéket az Advanced Options ESXi menüben. "Mem.AllocGuestLargePage" 0-ra (alapértelmezett 1). Ekkor a nagy memórialapok virtuális gépekhez való hozzárendelése le lesz tiltva.
2014 decembere óta az összes ESXi-kiadásban a virtuális gépek közötti TPS alapértelmezés szerint le van tiltva, mivel olyan sérülékenységet találtak, amely elméletileg lehetővé teszi, hogy egy virtuális gép hozzáférjen egy másik virtuális gép RAM-jához. Részletek itt. Nem találkoztam információval a TPS sebezhetőség kihasználásának gyakorlati megvalósításáról.
A TPS-házirend speciális opcióval vezérelhető „Mem.ShareForceSalting” ESXi-n:
0 - Inter-VM TPS. A TPS különböző virtuális gépek oldalain működik;
1 – TPS VMX-ben azonos „sched.mem.pshare.salt” értékkel rendelkező virtuális gépekhez;
2 (alapértelmezett) – VM-en belüli TPS. A TPS a virtuális gépeken belüli oldalakon működik.
Mindenképpen érdemes letiltani a nagy oldalakat, és engedélyezni az Inter-VM TPS-t a tesztpadokon. Ez sok hasonló virtuális géppel rendelkező állványokhoz is használható. Például a VDI-vel ellátott állványokon a fizikai memória megtakarítása elérheti a több tíz százalékot.
Memória léggömbök. A ballonozás már nem olyan ártalmatlan és átlátható technika a VM operációs rendszer számára, mint a TPS. De helyes használat esetén élhet és akár dolgozhat is a Ballooning segítségével.
A Vmware Tools-szal együtt egy speciális Balloon Driver (más néven vmmemctl) illesztőprogram van telepítve a virtuális gépre. Amikor a hypervisor kezd kifogyni a fizikai memóriából, és lágy állapotba kerül, az ESXi megkéri a virtuális gépet, hogy kérje vissza a fel nem használt RAM-ot ezen a ballon-illesztőprogramon keresztül. Az illesztőprogram pedig az operációs rendszer szintjén dolgozik, és szabad memóriát kér tőle. A hipervizor látja, hogy a ballon-illesztőprogram a fizikai memória mely oldalait foglalta el, memóriát vesz a virtuális gépből, és visszaküldi a gazdagépnek. Az operációs rendszer működésével nincs probléma, mivel az operációs rendszer szintjén a memóriát a Balloon Driver foglalja el. Alapértelmezés szerint a Balloon Driver a virtuális gép memóriájának akár 65%-át is elfoglalhatja.
Ha a VMware Tools nincs telepítve a virtuális gépre, vagy a Ballooning le van tiltva (nem ajánlom, de van :), a hypervisor azonnal átvált a szigorúbb memóriaeltávolítási technikákra. Következtetés: győződjön meg arról, hogy a VMware Tools a virtuális gépen van.
A Balloon Driver működése az operációs rendszerből a VMware Tools segítségével ellenőrizhető.
Memóriatömörítés. Ezt a technikát akkor használják, amikor az ESXi eléri a kemény állapotot. Ahogy a neve is sugallja, az ESXi egy 4 KB-os oldal RAM-ot próbál meg 2 KB-ra tömöríteni, ezzel felszabadítva némi helyet a szerver fizikai memóriájában. Ez a technika jelentősen megnöveli a VM RAM-oldalak tartalmához való hozzáférési időt, mivel az oldalt először ki kell tömöríteni. Néha nem lehet minden oldalt tömöríteni, és maga a folyamat eltart egy ideig. Ezért ez a technika a gyakorlatban nem túl hatékony.
Memóriacsere. A memóriatömörítés egy rövid szakasza után az ESXi szinte elkerülhetetlenül (ha a virtuális gépek nem költöztek át más gazdagépekre, vagy nincsenek kikapcsolva) cserére vált át. És ha nagyon kevés memória maradt (Alacsony állapot), akkor a hypervisor leállítja a memóriaoldalak kiosztását a virtuális gép számára, ami problémákat okozhat a virtuális gép vendég operációs rendszerében.
Így működik a csere. Amikor bekapcsol egy virtuális gépet, egy .vswp kiterjesztésű fájl jön létre hozzá. Mérete megegyezik a virtuális gép lefoglalt RAM-jával: ez a különbség a konfigurált és a fenntartott memória között. Amikor a Swapping fut, az ESXi a virtuális gép memóriaoldalait ebbe a fájlba cseréli, és ezzel kezd dolgozni a kiszolgáló fizikai memóriája helyett. Természetesen az ilyen „RAM” memória több nagyságrenddel lassabb, mint a valódi memória, még akkor is, ha a .vswp gyorstárhelyen van.
A Ballooningtől eltérően, amikor a nem használt oldalakat egy virtuális gépről veszik, a csereoldalak, amelyeket az operációs rendszer vagy a virtuális gépen belüli alkalmazások aktívan használnak, áthelyezhetők a lemezre. Ennek eredményeként a virtuális gép teljesítménye a lefagyásig csökken. A virtuális gép formálisan működik, és legalább megfelelően letiltható az operációs rendszerből. Ha türelmes vagy 😉
Ha a virtuális gépek a Swap szolgáltatásba kerültek, ez egy olyan vészhelyzet, amelyet lehetőleg el kell kerülni.
Alapvető virtuális gép memória teljesítményszámlálók
Szóval elérkeztünk a lényeghez. A virtuális gép memória állapotának figyeléséhez a következő számlálók állnak rendelkezésre:
Aktív — a virtuális gép által az előző mérési időszakban elért RAM mennyiségét (KB) mutatja.
Használat — ugyanaz, mint az Active, de a virtuális gép konfigurált RAM-jának százalékában. A következő képlettel számítva: aktív ÷ virtuális gép konfigurált memóriamérete.
A magas használat és az aktív érték nem mindig jelzi a virtuális gép teljesítményével kapcsolatos problémákat. Ha a virtuális gép agresszíven használja a memóriát (legalábbis hozzáfér), ez nem jelenti azt, hogy nincs elég memória. Ez inkább ok arra, hogy megnézzük, mi történik az operációs rendszerben.
Van egy szabványos riasztás a virtuális gépek memóriahasználatára vonatkozóan:
Közös — a TPS segítségével deduplikált virtuális gép RAM mennyisége (a virtuális gépen belül vagy virtuális gépek között).
Megadott — a virtuális géphez lefoglalt gazdagép fizikai memória (KB) mennyisége. Engedélyezi a Megosztott lehetőséget.
elfogyasztott (Megengedett – Megosztott) – a virtuális gép által a gazdagéptől felhasznált fizikai memória mennyisége (KB). Nem tartalmazza a Megosztott.
Ha a virtuálisgép-memória egy részét nem a gazdagép fizikai memóriájából, hanem egy swap fájlból adják meg, vagy a VM-ről a Balloon Driver-on keresztül vesznek el memóriát, akkor ez az összeg nem kerül figyelembevételre az Engedélyezett és elhasznált kategóriában.
A magas megadott és fogyasztott é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 egy aktívan futó virtuális gépben ezeknek a számlálóknak az értéke megközelíti a konfigurált memória mennyiségét, és ott is marad.
Nulla — a virtuális gép RAM mennyisége (KB), amely nullákat tartalmaz. Az ilyen memóriát a hypervisor szabadnak tekinti, és más virtuális gépeknek is megadható. Miután a vendég operációs rendszer írt valamit a nullázott memóriába, az a Consumed mappába kerül, és nem tér vissza.
Fenntartva rezsi — a VM RAM mennyisége (KB), amelyet a hypervisor a virtuális gép működéséhez tart fenn. Ez kevés, de elérhetőnek kell lennie a gazdagépen, különben a virtuális gép nem indul el.
Léggömb — a virtuális gépről Balloon Driver segítségével eltávolított RAM mennyisége (KB).
Sűrített — a tömörített RAM mennyisége (KB).
Cserélték — a RAM mennyisége (KB), amely a szerver fizikai memória hiánya miatt lemezre került.
A léggömbök és más memória-visszanyerési technikák számlálói nullák.
Így néz ki a grafikon egy normálisan működő, 150 GB RAM-mal rendelkező virtuális gép memóriaszámlálóival.
Az alábbi grafikonon a virtuális gépnek nyilvánvaló problémái vannak. A grafikon alatt látható, hogy ehhez a virtuális géphez a RAM-mal való munkavégzés összes leírt technikáját alkalmazták. A virtuális gép ballonja sokkal nagyobb, mint a Consumed. Valójában a VM inkább halott, mint él.
ESXTOP
A CPU-hoz hasonlóan, ha gyorsan szeretnénk felmérni a helyzetet a gazdagépen, valamint annak dinamikáját legfeljebb 2 másodperces intervallumban, akkor az ESXTOP-ot kell használnunk.
Az ESXTOP memória képernyőt az „m” gombbal hívja elő, és így néz ki (B,D,H,J,K,L,O mezők kiválasztva):
A következő paraméterek érdekelhetnek bennünket:
Mem overcommit átl — a gazdagépen 1, 5 és 15 percig tartó memória-túlfizetés átlagos értéke. Ha nulla felett van, akkor ez ok arra, hogy megnézzük, mi történik, de nem mindig jelzi a problémákat.
Sorokban PMEM/MB и VMKMEM/MB — információ a kiszolgáló fizikai memóriájáról és a VMkernel számára elérhető memóriáról. Itt az érdekességek között láthatjuk a minfree értéket (MB-ban), a memóriában lévő host állapotot (esetünkben high).
Sorban NUMA/MB láthatja a RAM eloszlását a NUMA csomópontok (socket) között. Ebben a példában az eloszlás egyenetlen, ami elvileg nem túl jó.
Az alábbi általános szerverstatisztikák a memória-visszanyerési technikákhoz:
PSHARE/MB — ezek a TPS statisztikák;
SWAP/MB — Swaphasználati statisztikák;
ZIP/MB — memóriaoldal-tömörítési statisztikák;
MEMCTL/MB — Balloon Driver használati statisztikák.
Egyéni virtuális gépek esetében a következő információk érdekelhetnek bennünket. A virtuális gépek nevét elrejtettem, nehogy összezavarjam a közönséget :). Ha az ESXTOP metrika hasonló a vSphere számlálójához, megadom a megfelelő számlálót.
MEMSZ — a virtuális gépen konfigurált memória mennyisége (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + érintetlen.
GRANT — MB-ben megadva.
TCHD — Aktív MByte-ban.
MCTL? — a Balloon Driver telepítve van-e a virtuális gépen.
MCTLSZ — Léggömb MB-nek.
MCTLGT — a RAM mennyisége (MByte), amelyet az ESXi el akar távolítani a virtuális gépről a Balloon Driver (Memctl Target) segítségével.
MCTLMAX — a RAM maximális mennyisége (MByte), amelyet az ESXi eltávolíthat a virtuális gépről a Balloon Driver segítségével.
SWCUR — a virtuális géphez a Swap fájlból lefoglalt RAM jelenlegi mennyisége (MByte).
S.W.G.T. — a RAM mennyisége (MByte), amelyet az ESXi a virtuális gépnek szeretne adni a cserefájlból (Swap Target).
A virtuális gép NUMA topológiájáról az ESXTOP-on keresztül is megtekinthet részletesebb információkat. Ehhez válassza ki a D, G mezőket:
KICSI – NUMA csomópontok, amelyeken a virtuális gép található. Itt azonnal észrevehető a széles vm, amely nem fér el egy NUMA csomóponton.
NRMEM – hány megabájt memóriát foglal el a virtuális gép a távoli NUMA csomóponttól.
NLMEM – hány megabájt memóriát foglal el a virtuális gép a helyi NUMA csomóponttól.
N%L – a virtuálisgép-memória százalékos aránya a helyi NUMA csomóponton (ha kevesebb, mint 80%, teljesítményproblémák léphetnek fel).
Memória a hipervizoron
Ha a hypervisor CPU-számlálói általában nem érdekesek, akkor a memóriával a helyzet fordított. A virtuális gépek magas memóriahasználata nem mindig jelent teljesítményproblémát, de a hypervisor magas memóriahasználata memóriakezelési technikákat vált ki, és problémákat okoz a virtuális gép teljesítményében. Figyelnie kell a gazdagép memóriahasználati riasztásait, és meg kell akadályoznia, hogy a virtuális gépek bejussanak a csereprogramba.
kicserélni
Ha egy virtuális gépet elkapnak a csereprogramban, teljesítménye jelentősen csökken. A léggömbök és a tömörítés nyomai gyorsan eltűnnek, miután a szabad RAM megjelenik a gazdagépen, de a virtuális gép nem siet vissza a Swapból a szerver RAM-jába.
Az ESXi 6.0 előtt az egyetlen megbízható és gyors módszer a virtuális gépek Swapból való eltávolítására az újraindítás (pontosabban a tároló ki-/bekapcsolása) volt. Az ESXi 6.0-tól kezdve, bár nem teljesen hivatalos, megjelent egy működő és megbízható módszer a virtuális gépek Swapból való eltávolítására. Az egyik konferencián beszélgethettem a VMware egyik CPU Schedulerért felelős mérnökével. Megerősítette, hogy a módszer meglehetősen működőképes és biztonságos. Tapasztalataink szerint ezzel sem volt probléma.
A virtuális gép Swapból való eltávolításának tényleges parancsai Duncan Epping. Nem ismétlem meg a részletes leírást, csak egy példát mondok a használatára. Amint a képernyőképen látható, a megadott parancs végrehajtása után egy idő után a Swap a virtuális gépen eltűnik.
Tippek a RAM kezeléséhez az ESXi rendszeren
Végül itt van néhány tipp, amelyek segítenek elkerülni a RAM miatti virtuális gép teljesítményével kapcsolatos problémákat:
- Kerülje el a RAM túlzott előfizetését a produktív fürtökben. Célszerű mindig ~20-30% szabad memória a fürtben, hogy a DRS-nek (és az adminisztrátornak) legyen mozgástere, és a VM-ek ne menjenek Swap-ba a migráció során. Ne feledkezzünk meg a hibatűrés határáról sem. Kellemetlen, amikor az egyik szerver meghibásodása és a virtuális gép újraindításakor a HA segítségével néhány gép is Swap-ra megy.
- Erősen konszolidált infrastruktúrákban NE hozzon létre olyan virtuális gépeket, amelyek memóriája nagyobb, mint a gazdagép memória fele. Ez ismét segít a DRS-nek abban, hogy a virtuális gépeket problémamentesen eloszthassa a fürtkiszolgálók között. Ez a szabály persze nem univerzális :).
- Vigyázzon a gazdagép memóriahasználati riasztására.
- Ne felejtse el telepíteni a VMware Tools programot a virtuális gépre, és ne kapcsolja ki a Ballooning funkciót.
- Fontolja meg az Inter-VM TPS engedélyezését és a Large Pages letiltását VDI- és tesztkörnyezetekben.
- Ha a virtuális gép teljesítménybeli problémákat tapasztal, ellenőrizze, hogy egy távoli NUMA-csomópont memóriáját használja-e.
- A lehető leggyorsabban távolítsa el a virtuális gépeket a Swapból! Többek között, ha a virtuális gép Swapban van, a tárolórendszer nyilvánvaló okokból szenved.
Nekem ennyi a RAM-ról. Az alábbiakban kapcsolódó cikkek találhatók azok számára, akik mélyebbre szeretnének menni. A következő cikket a storájnak szenteljük.
Hasznos Linkek
Forrás: will.com