V tomto článku se budeme věnovat měřičům výkonu operační paměti (RAM) ve vSphere.
S pamětí to vypadá jednoznačněji než s procesorem: pokud na VM nastanou problémy s výkonem, je obtížné je přehlédnout. Na druhou stranu, pokud se objeví, jejich řešení je mnohem složitější. Ale všechno hezky popořádku.
Trochu teorie
Operační paměť virtuálních strojů je čerpaná z paměti serveru, na kterém běží VM. To je zcela zřejmé :). Pokud serveru nestačí operační paměť pro všechny zájemce, ESXi začne používat techniky optimalizace spotřeby operační paměti (memory reclamation techniques). Jinak by operační systémy VM padaly s chybami při přístupu k RAM.
Které techniky použít, rozhoduje ESXi podle zatížení operační paměti:
Stav paměti
Hranice
Akce
High
400% z minFree
Po dosažení horní hranice se velké stránky paměti rozdělují na malé (TPS funguje ve standardním režimu).
Clear
100% z minFree
Velké stránky paměti se rozdělují na malé, TPS funguje nuceně.
Soft
64% z minFree
TPS + Balloon
Hard
32% z minFree
TPS + Compress + Swap
Low
16% z minFree
Compress + Swap + Block
minFree je operační paměť potřebná pro provoz hypervizora.
Až do verze ESXi 4.1 včetně byla minFree ve výchozím nastavení fixní — 6% objemu operační paměti serveru (procento bylo možné změnit pomocí volby Mem.MinFreePct na ESXi). V novějších verzích, kvůli nárůstu objemu paměti na serverech, se minFree začalo počítat na základě objemu paměti hostitele, nikoli jako fixní procentuální hodnota.
Hodnota minFree (ve výchozím nastavení) se počítá takto:
Procento paměti rezervované pro minFree
Rozsah paměti
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Zbývající paměť
Například pro server se 128 GB RAM bude hodnota MinFree následující:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Skutečná hodnota se může lišit o několik set MB, záleží na serveru a operační paměti.
Procento paměti rezervované pro minFree
Rozsah paměti
Hodnota pro 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Zbývající paměť (100 GB)
1024 MB
Obvykle se za normální stav pro produktivní prostředí považuje pouze stav High. Pro testovací a vývojové prostředí mohou být akceptovatelné stavy Clear/Soft. Pokud na hostiteli zůstává méně než 64 % MinFree operační paměti, mohou mít VM běžící na něm určitě problémy s výkonem.
V každém stavu se uplatňují určité techniky uvolňování paměti, počínaje TPS, což má prakticky minimální vliv na výkon VM, a konče swappingem. O těchto technikách se zmíním podrobněji.
Transparent Page Sharing (TPS). TPS je, zjednodušeně řečeno, deduplikace stránek operační paměti virtuálních strojů na serveru.
ESXi vyhledává shodné stránky operační paměti virtuálních strojů, vypočítává a porovnává hash sumu stránek a odstraňuje duplicitní stránky, nahrazující je odkazy na jednu a tutéž stránku v fyzické paměti serveru. Výsledkem je snížení spotřeby fyzické paměti a lze dosáhnout určité přepodpisování paměti prakticky bez zhoršení výkonu.
Tento mechanismus funguje pouze pro stránky paměti o velikosti 4 KB (malé stránky). Hypervizor se ani nepokouší deduplikovat stránky o velikosti 2 MB (velké stránky): šance najít shodné stránky takové velikosti není velká.
Od výchozího nastavení ESXi alokuje paměť velkým stránkám. Rozdělování velkých stránek na malé začíná při dosažení prahu stavu High a probíhá nuceně, když je dosaženo stavu Clear (viz tabulka stavů hypervizoru).
Pokud však chcete, aby TPS začal pracovat, aniž by čekal na zaplnění operační paměti hostitele, je v Advanced Options ESXi potřeba nastavit hodnotu “Mem.AllocGuestLargePage” na 0 (výchozí nastavení je 1). V takovém případě bude přidělování velkých stránek paměti pro virtuální stroje deaktivováno.
Od prosince 2014 je TPS mezi VM ve všech verzích ESXi výchozím nastavením deaktivován, protože byla objevena zranitelnost, která teoreticky umožňuje přístup z jedné VM k operační paměti jiné VM. Podrobnosti zde. Informace o praktické realizaci zneužití zranitelnosti TPS jsem nenalezl.
Politika TPS se kontroluje prostřednictvím pokročilé možnosti “Mem.ShareForceSalting” na ESXi:
0 — Inter-VM TPS. TPS funguje pro stránky různých VM;
1 – TPS pro VM se shodnou hodnotou “sched.mem.pshare.salt” v VMX;
2 (výchozí hodnoty) – Intra-VM TPS. TPS funguje pro stránky uvnitř VM.
Určitě dává smysl vypnout velké stránky a zapnout Inter-VM TPS na testovacích stáncích. To lze také využít pro stánky s velkým počtem podobných VM. Například na stáncích s VDI může úspora fyzické paměti dosáhnout desítek procent.
Memory Ballooning. Ballooning už není tak bezproblémová a transparentní technika pro operační systém VM, jako TPS. Ale při správném použití s Ballooningem lze žít a dokonce pracovat.
Spolu s VMware Tools se na VM instaluje speciální ovladač nazvaný Balloon Driver (také známý jako vmmemctl). Když hypervizor začne trpět nedostatkem fyzické paměti a přechází do stavu Soft, ESXi žádá VM, aby vrátila nevyužívanou operativní paměť prostřednictvím tohoto Balloon Drivera. Ovladač na oplátku pracuje na úrovni operačního systému a žádá ovolnou paměť od něj. Hypervizor vidí, které stránky fyzické paměti zabral Balloon Driver, přiděluje paměť od virtuálního počítače a vrací ji hostiteli. Problémy s prací OS nevznikají, protože na úrovni OS je paměť obsazená Balloon Driverem. Ve výchozím nastavení může Balloon Driver zabrat až 65 % paměti VM.
Pokud na VM nejsou nainstalovány VMware Tools nebo je Ballooning vypnut (nedoporučuji, ale je tu :), hypervizor okamžitě přechází k tvrdším technikám odebrání paměti. Závěr: Dbejte na to, aby byly VMware Tools na VM nainstalovány.
Funkčnost Balloon Drivera lze zkontrolovat z OS prostřednictvím VMware Tools..
Memory Compression. Tato technika se používá, když ESXi dosáhne stavu Hard. Jak název napovídá, ESXi se pokouší zkomprimovat 4 KB stránky operativní paměti na 2 KB a tím uvolnit trochu místa v fyzické paměti serveru. Tato technika výrazně zvyšuje dobu přístupu k obsahu stránek operativní paměti VM, protože stránku je třeba předem dekomprimovat. Někdy se nepodaří zkomprimovat všechny stránky a samotný proces zabere nějaký čas. Proto tato technika není v praxi příliš efektivní.
Memory Swapping. Po krátké fázi Memory Compression přechází ESXi téměř nevyhnutelně (pokud VM neopustily jiné hostitele nebo nejsou vypnuty) na Swapping. A pokud zbývá velmi málo paměti (stav Low), hypervizor také přestává přidělovat VM stránky paměti, což může způsobit problémy v hostitelských OS VM.
Jak funguje Swapping. Když se zapne virtuální stroj, vytvoří se pro něj soubor s příponou .vswp. Jeho velikost odpovídá rezervované operační paměti VMs: je to rozdíl mezi nakonfigurovanou a rezervovanou pamětí. Při Swappingu ESXi uvolňuje stránky paměti virtuálního stroje do tohoto souboru a začíná pracovat s ním místo fyzické paměti serveru. Samozřejmě, taková „operační“ paměť je o několik řádů pomalejší než skutečná, i když .vswp leží na rychlém úložišti.
Na rozdíl od Ballooningu, kdy se VM odeberou nepoužívané stránky, se při Swappingu na disk mohou přesunout stránky, které jsou aktivně používány OS nebo aplikacemi uvnitř VM. V důsledku toho se výkon VM může zhoršit až k zamrznutí. VM formálně funguje a je možné ji alespoň správně vypnout z OS. Pokud budete trpěliví 😉
Pokud VM přešla do Swap — je to abnormální situace, které by se bylo lepší vyhnout, pokud je to možné.
Hlavní ukazatele výkonu paměti virtuálního stroje
A jsme u toho hlavního. Pro sledování stavu paměti v VM existují následující ukazatele:
Aktivní — ukazuje objem operační paměti (Kbyte), ke kterému má VM přístup v předchozím měřicím období.
Použití — to samé jako Active, ale v procentech ze nakonfigurované operační paměti VM. Vypočítává se podle následujícího vzorce: active ÷ velikost nakonfigurované paměti virtuálního stroje.
Vysoký Usage a Active tedy ne vždy znamená, že existují problémy s výkonem VM. Pokud VM agresivně využívá paměť (alespoň na ni má přístup), neznamená to, že je paměti nedostatek. Spíše je to důvod podívat se, co se děje v OS.
Existuje standardní Alarm pro Memory Usage pro VM:
Sdílené — objem operační paměti VM, deduplikované pomocí TPS (uvnitř VM nebo mezi VM).
Odehráno — objem fyzické paměti hostitele (Kbyte), který byl přidělen VM. Zahrnuje sdílené.
Spotřebováno (Odehráno — Sdílené) — objem fyzické paměti (Kbyte), kterou VM spotřebovává z hostitele. Nezahrnuje sdílené.
Pokud část paměti VM je odebrána ne z fyzické paměti hostitele, ale ze swap souboru nebo byla paměť odebrána u VM prostřednictvím Balloon Driveru, tato část se nepočítá do Odehrané a Spotřebované.
Vysoké hodnoty Granted a Consumed jsou zcela normální. Operační systém postupně odebírá paměť hypervizoru a nevrací ji zpět. V průběhu času se hodnoty těchto ukazatelů aktivní virtuální stroje blíží objemu konfigurované paměti a tam zůstávají.
Nula — objem operační paměti virtuálního stroje (KB), která obsahuje nuly. Tato paměť je hypervizorem považována za volnou a může být přidělena jiným virtuálním strojům. Jakmile hostitelský operační systém zapíše něco do nulové paměti, ta přechází do stavu Consumed a už se nevrátí.
Reserved Overhead — objem operační paměti VM (KB) vyhrazený hypervizorem pro fungování VM. Je to malý objem, ale musí být na hostiteli k dispozici, jinak VM nenastartuje.
Balloon — objem operační paměti (KB), odebraný VM pomocí Balloon Driver.
Compressed — objem operační paměti (KB), kterou se podařilo zkomprimovat.
Swapped — objem operační paměti (KB), která se v důsledku nedostatku fyzické paměti na serveru přesunula na disk.
Balloon a ostatní ukazatele memory reclamation techniques jsou rovny nule.
Takto vypadá graf se statistikami normálně fungující VM s 150 GB operační paměti.
Na grafu níže má VM jasné problémy. Pod grafem je vidět, že pro tuto VM byly použity všechny popsané techniky práce s operační pamětí. Balloon pro tuto VM je výrazně větší než Consumed. V podstatě je VM spíše mrtvá než živá.
ESXTOP
Stejně jako u CPU, pokud chceme rychle zhodnotit situaci na hostiteli, stejně jako její dynamiku s intervalem do 2 sekund, stojí za to využít ESXTOP.
Obrazovka ESXTOP pro paměť se vyvolává klávesou „m“ a vypadá takto (byla vybrána pole B, D, H, J, K, L, O):
Zajímavé pro nás budou následující parametry:
Mem overcommit avg — průměrná hodnota přetížení paměti na hostiteli za 1, 5 a 15 minut. Pokud je nad nulou, je to důvod se podívat, co se děje, ale ne vždy ukazuje na přítomnost problémů.
V řádcích PMEM/MB a VMKMEM/MB — informace o fyzické paměti serveru a paměti dostupné VMkernel. Zajímavé je zde vidět hodnotu minfree (v MB), stav hostitele po paměti (v našem případě vysoký).
Ve řádku NUMA/MB můžete vidět rozdělení operační paměti podle NUMA uzlů (socketů). V tomto příkladu je rozdělení nevyvážené, což není příliš dobré.
Následuje celková statistika serveru o technikách uvolňování paměti:
PSHARE/MB — je to statistika TPS;
SWAP/MB — statistika použití swapu;
ZIP/MB — statistika komprese stránek paměti;
MEMCTL/MB — statistika využití Balloon Driveru.
U jednotlivých VM nás může zajímat následující informace. Jména VM jsem skryl, abych nezmátl publikum:). Pokud je metrika ESXTOP srovnatelná s čítačem ve vSphere, uvádím odpovídající čítač.
MEMSZ — objem paměti konfigurovaný na VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
UDĚLOVAT — Granted v MB.
TCHD — Active v MB.
MCTL? — je na VM nainstalován Balloon Driver.
MCTLSZ — Balloon v MB.
MCTLGT — objem operační paměti (MB), který ESXi chce odebrat z VM prostřednictvím Balloon Driveru (Memctl Target).
MCTLMAX — maximální objem operační paměti (MB), který ESXi může odebrat z VM prostřednictvím Balloon Driveru.
SWCUR — aktuální objem operační paměti (MB), který byl VM přidělen ze swap souboru.
SWGT — objem operační paměti (MB), který ESXi chce přidělit VM ze swap souboru (Swap Target).
Dále pomocí ESXTOP můžete zobrazit podrobnější informace o NUMA topologii VM. K tomu je třeba vybrat pole D,G:
NHN – NUMA uzly, na kterých je VM umístěna. Tady si můžete okamžitě všimnout širokých VM, které se nevejdou na jeden NUMA uzel.
NRMEM – kolik megabajtů paměti VM bere z vzdáleného NUMA uzlu.
NLMEM – kolik megabajtů paměti VM bere z místního NUMA uzlu.
N%L – procento paměti VM na místním NUMA uzlu (pokud je méně než 80% — mohou nastat problémy s výkonem).
Paměť na hypervizoru
Pokud čítače CPU na hypervizoru obvykle nezaznamenávají zvláštní zájem, situace s pamětí je opačná. Vysoké využití paměti na VM ne vždy naznačuje problém s výkonem, ale vysoké využití paměti na hypervizoru spouští techniky správy paměti a způsobuje problémy s výkonem VM. Je třeba sledovat alarmy Host Memory Usage a nedovolit VM dostat se do swapu.
Unswap
Pokud se VM dostane do swapu, její výkon se výrazně snižuje. Stopy ballooningu a komprese rychle mizí po zvýšení volné operační paměti na hostiteli, ale návrat z swapu do operační paměti serveru se virtuální stroj rozhodně nehněte.
Až do verze ESXi 6.0 byl jediným spolehlivým a rychlým způsobem, jak vyvést VM ze Swap, restart (přesněji vypnutí/zapnutí kontejneru). Od verze ESXi 6.0 se objevil sice ne úplně oficiální, ale funkční a spolehlivý způsob, jak vyvést VM ze Swap. Na jedné z konferencí jsem měl možnost hovořit s jedním z inženýrů VMware, který byl zodpovědný za plánovač CPU. Potvrdil, že tento způsob je zcela funkční a bezpečný. V naší praxi jsme s ním také nezaznamenali žádné problémy.
Ve skutečnosti příkazy pro vyvádění VM ze Swap Duncan Epping. Nechci opakovat podrobný popis, prostě uvedu příklad jeho použití. Jak je vidět na screenshotu, po určité době po provedení uvedeného příkazu Swap na VM zmizí.
Tipy pro správu operační paměti na ESXi
Na závěr uvedu několik tipů, které vám mohou pomoci vyhnout se problémům s výkonem VM kvůli operační paměti:
- Nedovolte překročení kapacity operační paměti v produktivních clusterech. Je žádoucí mít vždy ~20-30 % volné paměti v clusteru, aby měl DRS (a správce) místo pro manévrování a během migrace VM se nedostaly do Swap. Také nezapomínejte na rezervu pro vysokou dostupnost. Není příjemné, když při výpadku jednoho serveru a restartování VM pomocí HA část strojů ještě odejde do Swap.
- V infrastrukturách s vysokou konsolidací se snažte NEEVYTVÁŘET VM s pamětí větší než polovina paměti hostitele. To opět pomůže DRS bez problémů rozdělovat virtuální stroje mezi servery clusteru. Toto pravidlo samozřejmě není univerzální :).
- Dávejte pozor na alarm vyžití paměti hostitele.
- Nezapomínejte instalovat VMware Tools na VM a nevypínat Ballooning.
- Zvažte možnost zapnutí Inter-VM TPS a vypnutí Large Pages v prostředích s VDI a testovacích prostředích.
- Pokud VM zažívá problémy s výkonem, zkontrolujte, zda nepoužívá paměť z vzdáleného NUMA uzlu.
- Vyvádějte VM ze Swap co nejrychleji! Kromě všeho ostatního, pokud je VM ve Swap, trpí zřejmým způsobem také SANS.
Tímto končím s operační pamětí. Níže jsou uvedeny články na toto téma pro ty, kteří chtějí proniknout do detailů. Další článek se bude věnovat úložišti.
Užitečné odkazy
Zdroj: habr.com
