V tomto článku budeme hovořit o čítačích výkonu paměti RAM (Random Access Memory) ve vSphere.
Zdá se, že s pamětí je vše přehlednější než s procesorem: pokud má virtuální počítač problémy s výkonem, je těžké si jich nevšimnout. Pokud se ale objeví, je mnohem obtížnější se s nimi vypořádat. Ale nejdřív.
Některé teorie
RAM virtuálních strojů se bere z paměti serveru, na kterém běží virtuální počítače. Je to celkem jasné :). Pokud RAM serveru nestačí pro každého, ESXi začne používat techniky rekultivace paměti k optimalizaci spotřeby RAM. Jinak by operační systémy virtuálních počítačů spadly s chybami přístupu k paměti RAM.
Které techniky použít ESXi se rozhoduje v závislosti na zatížení paměti RAM:
Stav paměti
hraniční
Činnost
Vysoký
400 % minZdarma
Po dosažení horní hranice se velké paměťové stránky rozdělí na malé (TPS pracuje ve standardním režimu).
Zrušit
100 % minZdarma
Velké paměťové stránky jsou rozděleny na malé, TPS je nucen pracovat.
Měkký
64 % minZdarma
TPS + balón
Tvrdý
32 % minZdarma
TPS + Komprimovat + Swap
Nízké
16 % minZdarma
Komprimovat + Swap + Blokovat
minFree je RAM požadovaná pro fungování hypervizoru.
Před ESXi 4.1 včetně bylo minFree ve výchozím nastavení opraveno – 6 % RAM serveru (procento bylo možné změnit pomocí možnosti Mem.MinFreePct na ESXi). V pozdějších verzích, kvůli nárůstu velikosti paměti na serverech, se minFree začal vypočítávat na základě množství paměti hostitele a ne jako pevné procento.
Hodnota minFree (výchozí) se vypočítá následovně:
Procento paměti vyhrazené 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 by hodnota MinFree byla:
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 stovek MB, záleží na serveru a RAM.
Procento paměti vyhrazené pro minFree
Rozsah paměti
Hodnota za 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 lze u produkčních porostů považovat za normální pouze stav Vysoký. Pro testovací a vývojové stolice mohou být přijatelné stavy Clear/Soft. Pokud je RAM na hostiteli menší než 64 % MinFree, pak virtuální počítače na něm běžící mají určitě problémy s výkonem.
V každém stavu jsou aplikovány určité techniky rekultivace paměti, počínaje TPS, které prakticky neovlivňují výkon VM, a konče Swappingem. Řeknu vám o nich víc.
Transparentní sdílení stránek (TPS). TPS je, zhruba řečeno, deduplikace stránek paměti virtuálního stroje na serveru.
ESXi hledá identické stránky paměti RAM virtuálního stroje počítáním a porovnáváním hašovacího součtu stránek a odstraňuje duplicitní stránky a nahrazuje je odkazy na stejnou stránku ve fyzické paměti serveru. Výsledkem je snížení spotřeby fyzické paměti a určitého nadměrného odběru paměti lze dosáhnout s malým nebo žádným snížením výkonu.
Tento mechanismus funguje pouze pro 4 KB paměťové stránky (malé stránky). Hypervizor se ani nesnaží odstranit duplicitní stránky o velikosti 2 MB (velké stránky): šance najít identické stránky této velikosti není velká.
Ve výchozím nastavení ESXi přiděluje paměť velkým stránkám. Rozdělování velkých stránek na malé stránky začíná při dosažení prahu stavu High a je vynuceno při dosažení stavu Clear (viz tabulka stavů hypervizoru).
Pokud chcete, aby TPS začal pracovat bez čekání na zaplnění hostitelské RAM, v Rozšířených možnostech ESXi musíte nastavit hodnotu “Mem.AllocGuestLargePage” na 0 (výchozí 1). Poté bude přidělování velkých stránek paměti pro virtuální stroje zakázáno.
Od prosince 2014 je ve všech verzích ESXi TPS mezi VM ve výchozím nastavení zakázáno, protože byla nalezena zranitelnost, která teoreticky umožňuje přístup z jednoho VM do RAM jiného VM. Podrobnosti zde. Na informace o praktické implementaci zneužití zranitelnosti TPS jsem nenarazil.
Zásady TPS ovládané prostřednictvím pokročilé možnosti "Mem.ShareForceSalting" na ESXi:
0 - Inter-VM TPS. TPS funguje pro stránky různých virtuálních počítačů;
1 – TPS pro VM se stejnou hodnotou „sched.mem.pshare.salt“ ve VMX;
2 (výchozí) - Intra-VM TPS. TPS funguje pro stránky uvnitř virtuálního počítače.
Rozhodně má smysl vypnout velké stránky a zapnout Inter-VM TPS na testovacích stolicích. Lze jej použít i pro stojany s velkým počtem stejného typu VM. Například na stojanech s VDI může úspora fyzické paměti dosáhnout desítek procent.
balónování paměti. Ballooning již není tak neškodnou a transparentní technikou pro operační systém VM jako TPS. Ale se správnou aplikací můžete žít a dokonce pracovat s balónem.
Společně s Vmware Tools je na virtuálním počítači nainstalován speciální ovladač s názvem Balloon Driver (aka vmmemctl). Když hypervizoru začne docházet fyzická paměť a přejde do měkkého stavu, ESXi požádá VM, aby znovu získal nevyužitou RAM prostřednictvím tohoto ovladače Balloon Driver. Ovladač zase pracuje na úrovni operačního systému a požaduje od něj volnou paměť. Hypervizor vidí, které stránky fyzické paměti Balloon Driver zabral, vezme paměť z virtuálního počítače a vrátí ji hostiteli. S provozem OS nejsou žádné problémy, protože na úrovni OS je paměť obsazena Balloon Driverem. Ve výchozím nastavení může Balloon Driver zabírat až 65 % paměti virtuálního počítače.
Pokud na virtuálním počítači nejsou nainstalovány nástroje VMware nebo je zakázáno vytváření bublin (nedoporučuji, ale existují :), hypervizor okamžitě přejde na přísnější techniky odstraňování paměti. Závěr: Ujistěte se, že nástroje VMware jsou na virtuálním počítači.
Činnost ovladače Balloon Driver lze zkontrolovat z operačního systému pomocí VMware Tools.
komprese paměti. Tato technika se používá, když ESXi dosáhne stavu Hard. Jak název napovídá, ESXi se pokouší zmenšit 4KB stránku RAM na 2KB a uvolnit tak místo ve fyzické paměti serveru. Tato technika výrazně prodlužuje dobu přístupu k obsahu stránek VM RAM, protože stránku je nutné nejprve dekomprimovat. Někdy nelze komprimovat všechny stránky a samotný proces nějakou dobu trvá. Proto tato technika není v praxi příliš účinná.
výměna paměti. Po krátké fázi komprese paměti ESXi téměř nevyhnutelně (pokud virtuální počítače neodešly na jiné hostitele nebo se nevypnuly) přepne na Swapping. A pokud zbývá velmi málo paměti (nízký stav), pak hypervizor také přestane přidělovat stránky paměti virtuálnímu počítači, což může způsobit problémy v hostujícím OS virtuálního počítače.
Zde je návod, jak funguje Swapping. Když virtuální počítač zapnete, vytvoří se pro něj soubor s příponou .vswp. Velikostí se rovná nerezervované paměti RAM virtuálního počítače: je to rozdíl mezi nakonfigurovanou a rezervovanou pamětí. Když běží Swapping, ESXi uvolní stránky paměti virtuálního stroje do tohoto souboru a začne s ním pracovat namísto fyzické paměti serveru. Taková „operativní“ paměť je samozřejmě o několik řádů pomalejší než ta skutečná, i když .vswp leží na rychlém úložišti.
Na rozdíl od Ballooningu, kdy jsou z virtuálního počítače převzaty nepoužívané stránky, se pomocí Swappingu mohou stránky, které aktivně používá operační systém nebo aplikace uvnitř virtuálního počítače, přesunout na disk. Výsledkem je, že výkon VM klesá až k bodu mrazu. Virtuální počítač formálně funguje a alespoň jej lze z OS řádně deaktivovat. Pokud budete trpěliví 😉
Pokud virtuální počítače přešly do Swapu, jedná se o abnormální situaci, které je nejlepší se pokud možno vyhnout.
Čítače výkonu paměti klíčového virtuálního počítače
Tak jsme se dostali k hlavnímu bodu. Ke sledování stavu paměti ve virtuálním počítači existují následující čítače:
Aktivní — zobrazuje množství paměti RAM (KB), ke které získal virtuální počítač přístup v předchozím období měření.
Používání - stejné jako Active, ale jako procento nakonfigurované RAM virtuálního počítače. Vypočítá se pomocí následujícího vzorce: aktivní ÷ velikost paměti nakonfigurovaná virtuálním počítačem.
Vysoké využití a aktivní nejsou vždy indikátorem problémů s výkonem virtuálního počítače. Pokud virtuální počítač agresivně používá paměť (alespoň k ní získá přístup), neznamená to, že není dostatek paměti. Spíše je to příležitost vidět, co se děje v OS.
Pro virtuální počítače existuje standardní alarm využití paměti:
Společná - množství VM RAM deduplikované pomocí TPS (uvnitř VM nebo mezi VM).
Udělil - množství fyzické paměti hostitele (KB), které bylo přiděleno virtuálnímu počítači. Zahrnuje Sdílené.
Spotřebováno (Granted – Shared) – množství fyzické paměti (KB), kterou virtuální počítač spotřebovává od hostitele. Nezahrnuje Sdílené.
Pokud část paměti virtuálního počítače není dána z fyzické paměti hostitele, ale z odkládacího souboru, nebo je paměť převzata z virtuálního počítače prostřednictvím ovladače Balloon Driver, toto množství se v Granted and Consumed nebere v úvahu.
Vysoké hodnoty udělené a spotřebované jsou naprosto normální. Operační systém postupně odebírá paměť hypervizoru a nevrací ji zpět. Postupem času se v aktivně spuštěném virtuálním počítači hodnoty těchto čítačů přiblíží velikosti nakonfigurované paměti a zůstanou tam.
Nulu — množství paměti VM RAM (KB), která obsahuje nuly. Taková paměť je hypervizorem považována za volnou a může být poskytnuta jiným virtuálním strojům. Poté, co hostující OS něco zapsal do vynulované paměti, přejde do stavu Consumed a nevrátí se zpět.
Vyhrazená režie — množství paměti RAM virtuálního počítače (KB) vyhrazené hypervizorem pro provoz virtuálního počítače. Toto je malé množství, ale musí být dostupné na hostiteli, jinak se virtuální počítač nespustí.
Balón — množství paměti RAM (KB) obsazené virtuálním počítačem pomocí ovladače Balloon Driver.
Stlačený - množství paměti RAM (KB), které bylo komprimováno.
Vyměnil - množství paměti RAM (KB), která byla kvůli nedostatku fyzické paměti na serveru přesunuta na disk.
Počítadla balonových a jiných technik rekultivace paměti jsou nulová.
Takto vypadá graf s počítadly paměti pro normálně pracující VM se 150 GB RAM.
V níže uvedeném grafu má VM zjevné problémy. Pod grafem vidíte, že pro tento VM byly použity všechny popsané techniky pro práci s RAM. Balloon pro tento VM je mnohem větší než Consumed. Ve skutečnosti je VM více mrtvý než živý.
ESXTOP
Stejně jako u CPU, pokud chceme rychle posoudit situaci na hostiteli a také jeho dynamiku s intervalem do 2 sekund, měli bychom použít ESXTOP.
Obrazovka ESXTOP pomocí paměti se vyvolá klávesou „m“ a vypadá takto (jsou vybrána pole B, D, H, J, K, L, O):
Budou nás zajímat následující parametry:
Mem overcommit prům - průměrná hodnota nadměrného odběru paměti na hostiteli po dobu 1, 5 a 15 minut. Pokud je nad nulou, pak je to příležitost vidět, co se děje, ale ne vždy indikátor problémů.
V řádcích PMEM/MB и VMKMEM/MB - informace o fyzické paměti serveru a paměti dostupné pro VMkernel. Ze zajímavosti zde můžete vidět hodnotu minfree (v MB), stav hostitele v paměti (v našem případě vysoký).
V souladu NUMA/MB můžete vidět distribuci RAM podle NUMA uzlů (socketů). V tomto příkladu je rozložení nerovnoměrné, což v zásadě není příliš dobré.
Níže jsou uvedeny obecné statistiky serveru o technikách rekultivace paměti:
PSHARE/MB jsou statistiky TPS;
SWAP/MB — Swap statistiky využití;
ZIP/MB — statistika komprese stránky paměti;
MEMCTL/MB — Statistiky využití Balloon Driver.
U jednotlivých VM nás mohou zajímat následující informace. Jména VM jsem schoval, abych nezmátl publikum :). Pokud je metrika ESXTOP podobná počítadlu ve vSphere, dávám odpovídající počítadlo.
MEMSZ — množství paměti nakonfigurované na virtuálním počítači (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + nedotčeno.
GRANT — Uděleno MB.
TCHD — Aktivní v MB.
MCTL? - zda je na virtuálním počítači nainstalován ovladač Balloon Driver.
MCTLSZ — Balón do MB.
MCTLGT — množství paměti RAM (MB), kterou chce ESXi odebrat z virtuálního počítače pomocí ovladače Balloon Driver (Memctl Target).
MCTLMAX - maximální množství paměti RAM (MB), kterou může ESXi odebrat z virtuálního počítače prostřednictvím ovladače Balloon Driver.
SWCUR — aktuální množství paměti RAM (MB) přidělené virtuálnímu počítači z odkládacího souboru.
S.W.G.T. - množství paměti RAM (MB), kterou chce ESXi dát virtuálnímu počítači z odkládacího souboru (swap Target).
Prostřednictvím ESXTOP můžete také zobrazit podrobnější informace o topologii NUMA virtuálního počítače. Chcete-li to provést, vyberte pole D, G:
MALÝ – NUMA uzlů, na kterých je virtuální počítač umístěn. Zde si můžete okamžitě všimnout širokých vm, které se nevejdou na jeden uzel NUMA.
NRMEM - kolik megabajtů paměti virtuální počítač zabere ze vzdáleného uzlu NUMA.
NLMEM - kolik megabajtů paměti zabírá virtuální počítač z místního uzlu NUMA.
N%L – procento paměti virtuálního počítače v místním uzlu NUMA (je-li menší než 80 %, mohou nastat problémy s výkonem).
Paměť na hypervisoru
Pokud čítače CPU pro hypervisor obvykle nejsou zvláště zajímavé, pak je situace obrácená s pamětí. Vysoké využití paměti na virtuálním počítači neznamená vždy 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 na virtuálním počítači. Alarmy využití paměti hostitele musí být monitorovány, aby se virtuální počítač nedostal do Swapu.
Vyměnit
Pokud je virtuální počítač ve swapu, jeho výkon je výrazně snížen. Stopy balónování a komprese rychle zmizí poté, co se na hostiteli objeví volná RAM, ale virtuální stroj nijak nespěchá, aby se vrátil z Swap do RAM serveru.
Před ESXi 6.0 byl jediným spolehlivým a rychlým způsobem, jak dostat virtuální počítač z Swapu, restart (přesněji vypnout/zapnout kontejner). Počínaje ESXi 6.0, i když ne zcela oficiální, se objevil fungující a spolehlivý způsob, jak odstranit VM ze Swapu. Na jedné z konferencí jsem mohl mluvit s jedním z inženýrů VMware, kteří měli na starosti plánovač CPU. Potvrdil, že metoda je docela funkční a bezpečná. Ani s tím podle našich zkušeností nebyly žádné problémy.
Skutečné příkazy pro odebrání virtuálního počítače ze swapu Duncan Epping. Nebudu opakovat podrobný popis, jen uvedu příklad jeho použití. Jak můžete vidět na snímku obrazovky, nějakou dobu po provedení zadaných příkazů Swap na virtuálním počítači zmizí.
Tipy pro správu paměti ESXi
Nakonec je zde několik tipů, které vám pomohou vyhnout se problémům s výkonem VM kvůli RAM:
- Vyhněte se nadměrnému odběru paměti v produktivních clusterech. Je žádoucí mít vždy ~20-30% volné paměti v clusteru, aby DRS (a správce) měli prostor pro manévrování a virtuální počítače během migrace nepřecházely do Swapu. Také nezapomeňte na rezervu pro odolnost proti chybám. Je nepříjemné, když když jeden server selže a VM je restartován pomocí HA, některé stroje také přejdou do Swapu.
- Ve vysoce konsolidovaných infrastrukturách se snažte NEVYTVÁRAT virtuální počítače s více než polovinou paměti hostitele. To opět pomůže DRS distribuovat virtuální stroje mezi servery clusteru bez jakýchkoli problémů. Toto pravidlo samozřejmě není univerzální :).
- Sledujte alarm využití paměti hostitele.
- Nezapomeňte nainstalovat VMware Tools na VM a nevypínejte Ballooning.
- Zvažte povolení Inter-VM TPS a zakázání velkých stránek ve VDI a testovacích prostředích.
- Pokud má virtuální počítač problémy s výkonem, zkontrolujte, zda nevyužívá paměť ze vzdáleného uzlu NUMA.
- Dostaňte svůj VM ze Swapu co nejrychleji! Mimo jiné, pokud je VM ve Swapu, z pochopitelných důvodů trpí úložný systém.
To je pro mě o RAM vše. Níže je související článek pro ty, kteří se chtějí ponořit do podrobností. Příští článek bude věnován storadzh.
Užitečné odkazy
Zdroj: www.habr.com