V tem članku bomo govorili o števcih zmogljivosti pomnilnika z naključnim dostopom (RAM) v vSphere.
Zdi se, da je s pomnilnikom vse bolj jasno kot s procesorjem: če ima VM težave z zmogljivostjo, jih je težko ne opaziti. Če pa se pojavijo, se je z njimi veliko težje spopasti. Ampak najprej.
Malo teorije
RAM virtualnih strojev je vzet iz pomnilnika strežnika, na katerem se izvajajo VM. Je čisto očitno :). Če RAM-a strežnika ni dovolj za vse, ESXi začne uporabljati tehnike pridobivanja pomnilnika za optimizacijo porabe RAM-a. V nasprotnem primeru bi se operacijski sistemi VM zrušili z napakami pri dostopu do RAM-a.
Katere tehnike uporabiti, se ESXi odloči glede na obremenitev RAM-a:
Stanje pomnilnika
meja
Dejavnost
visoka
400 % minFree
Ko dosežete zgornjo mejo, se velike pomnilniške strani razdelijo na majhne (TPS deluje v standardnem načinu).
Počisti
100 % minFree
Velike pomnilniške strani so razdeljene na majhne, TPS je prisiljen delovati.
Soft
64 % minFree
TPS + balon
Trdi
32 % minFree
TPS + Stisni + Zamenjaj
nizka
16 % minFree
Stisni + Zamenjaj + Blokiraj
minFree je RAM, potreben za delovanje hipervizorja.
Pred vključno ESXi 4.1 je bil minFree privzeto popravljen - 6 % strežniškega RAM-a (odstotek je bilo mogoče spremeniti prek možnosti Mem.MinFreePct na ESXi). V kasnejših različicah se je zaradi povečanja velikosti pomnilnika na strežnikih minFree začel izračunavati glede na količino pomnilnika gostitelja in ne kot fiksni odstotek.
MinFree (privzeta) vrednost se izračuna na naslednji način:
Odstotek pomnilnika, rezerviranega za minFree
Obseg pomnilnika
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Preostali pomnilnik
Na primer, za strežnik s 128 GB RAM-a bi bila vrednost MinFree:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Dejanska vrednost se lahko razlikuje za nekaj sto MB, odvisno od strežnika in RAM-a.
Odstotek pomnilnika, rezerviranega za minFree
Obseg pomnilnika
Vrednost 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%
Preostali pomnilnik (100 GB)
1024 MB
Običajno se lahko za produktivne sestoje samo visoko stanje šteje za normalno. Za preskusne in razvojne mize so lahko sprejemljiva stanja Clear/Soft. Če je RAM na gostitelju manjši od 64 % MinFree, potem imajo navidezni računalniki, ki se izvajajo na njem, zagotovo težave z zmogljivostjo.
V vsakem stanju se uporabljajo določene tehnike pridobivanja pomnilnika, začenši s TPS, ki praktično ne vpliva na zmogljivost VM, in konča z zamenjavo. Povedal vam bom več o njih.
Transparent Page Sharing (TPS). TPS je, grobo rečeno, deduplikacija pomnilniških strani navideznega stroja na strežniku.
ESXi išče identične strani RAM-a virtualnega stroja s štetjem in primerjavo zgoščene vsote strani ter odstrani podvojene strani in jih nadomesti s povezavami do iste strani v fizičnem pomnilniku strežnika. Posledično se zmanjša poraba fizičnega pomnilnika in nekaj prevelike naročnine na pomnilnik je mogoče doseči z majhnim poslabšanjem zmogljivosti ali brez njega.
Ta mehanizem deluje samo za 4 KB pomnilniške strani (majhne strani). Hipervizor niti ne poskuša razdvojiti strani velikosti 2 MB (velike strani): možnost, da bi našli enake strani te velikosti, ni velika.
ESXi privzeto dodeli pomnilnik velikim stranem. Razbijanje velikih strani na majhne se začne, ko je dosežen visok prag stanja, in je vsiljeno, ko je doseženo stanje Počisti (glejte tabelo stanja hipervizorja).
Če želite, da TPS začne delovati, ne da bi čakali, da se pomnilnik gostitelja napolni, morate v naprednih možnostih ESXi nastaviti vrednost »Mem.AllocGuestLargePage« na 0 (privzeto 1). Nato bo dodeljevanje velikih pomnilniških strani za virtualne stroje onemogočeno.
Od decembra 2014 je v vseh izdajah ESXi TPS med VM-ji privzeto onemogočen, saj je bila ugotovljena ranljivost, ki teoretično omogoča dostop z enega VM-ja do RAM-a drugega VM-ja. Podrobnosti tukaj. Nisem naletel na informacije o praktični izvedbi izkoriščanja ranljivosti TPS.
Politika TPS, nadzorovana prek napredne možnosti »Mem.ShareForceSalting« na ESXi:
0 - Inter-VM TPS. TPS deluje za strani različnih virtualnih strojev;
1 – TPS za VM z enako vrednostjo »sched.mem.pshare.salt« v VMX;
2 (privzeto) – Intra-VM TPS. TPS deluje za strani znotraj VM.
Vsekakor je smiselno izključiti velike strani in vklopiti Inter-VM TPS na testnih mizah. Lahko se uporablja tudi za stojala z velikim številom istega tipa VM. Na primer, na stojalih z VDI lahko prihranki v fizičnem pomnilniku dosežejo več deset odstotkov.
napihovanje spomina. Baloniranje ni več tako neškodljiva in pregledna tehnika za operacijski sistem VM kot TPS. Toda s pravilno uporabo lahko živite in celo delate z Ballooningom.
Skupaj z orodji Vmware je na VM nameščen poseben gonilnik, imenovan Balloon Driver (aka vmmemctl). Ko hipervizorju začne zmanjkovati fizičnega pomnilnika in preide v mehko stanje, ESXi od VM zahteva, da prek tega balonskega gonilnika povrne neuporabljen RAM. Gonilnik pa deluje na ravni operacijskega sistema in od njega zahteva prosti pomnilnik. Hipervizor vidi, katere strani fizičnega pomnilnika je Balloon Driver zasedel, vzame pomnilnik iz virtualnega stroja in ga vrne gostitelju. Z delovanjem OS ni težav, saj na nivoju OS pomnilnik zasede gonilnik Balloon Driver. Gonilnik Balloon lahko privzeto zasede do 65 % pomnilnika VM.
Če orodja VMware Tools niso nameščena na VM ali je Ballooning onemogočen (ne priporočam, vendar obstajajo :), hipervizor takoj preklopi na strožje tehnike odstranjevanja pomnilnika. Zaključek: poskrbite, da so orodja VMware na VM.
Delovanje gonilnika Balloon Driver je mogoče preveriti iz operacijskega sistema prek orodij VMware.
stiskanje pomnilnika. Ta tehnika se uporablja, ko ESXi doseže trdo stanje. Kot pove že ime, poskuša ESXi skrčiti 4KB stran RAM-a v 2KB in tako sprostiti nekaj prostora v fizičnem pomnilniku strežnika. Ta tehnika bistveno poveča čas dostopa do vsebine strani VM RAM, saj je treba stran najprej nestisniti. Včasih ni mogoče stisniti vseh strani in sam postopek traja nekaj časa. Zato ta tehnika v praksi ni preveč učinkovita.
zamenjava pomnilnika. Po kratki fazi stiskanja pomnilnika bo ESXi skoraj neizogibno (če VM-ji niso odšli na druge gostitelje ali se izklopili) preklopil na zamenjavo. In če ostane zelo malo pomnilnika (nizko stanje), potem tudi hipervizor preneha dodeljevati pomnilniške strani VM, kar lahko povzroči težave v gostujočem OS VM.
Tukaj je opisano, kako deluje zamenjava. Ko vklopite virtualni stroj, se zanj ustvari datoteka s pripono .vswp. Po velikosti je enak nerezerviranemu RAM-u VM: je razlika med konfiguriranim in rezerviranim pomnilnikom. Ko se izvaja zamenjava, ESXi razloži pomnilniške strani navideznega stroja v to datoteko in začne delati z njo namesto s fizičnim pomnilnikom strežnika. Seveda je takšen "operativni" pomnilnik za nekaj velikosti počasnejši od pravega, tudi če .vswp leži na hitrem pomnilniku.
Za razliko od baloniranja, ko so neuporabljene strani vzete iz VM, se lahko z zamenjavo strani, ki jih aktivno uporablja OS ali aplikacije znotraj VM, premaknejo na disk. Posledično se zmogljivost VM zmanjša do točke zmrzovanja. VM formalno deluje in ga je vsaj mogoče pravilno onemogočiti v OS. Če ste potrpežljivi 😉
Če so VM-ji prešli na Swap, je to neobičajna situacija, ki se ji je najbolje izogniti, če je le mogoče.
Ključni števci zmogljivosti pomnilnika VM
Pa smo prišli do bistva. Za spremljanje stanja pomnilnika v VM so na voljo naslednji števci:
Aktivno — prikazuje količino RAM-a (KB), do katerega je VM dobil dostop v prejšnjem merilnem obdobju.
Uporaba - enako kot Active, vendar kot odstotek konfiguriranega RAM-a VM. Izračunano z naslednjo formulo: aktivni ÷ velikost konfiguriranega pomnilnika navideznega stroja.
Visoka poraba oziroma aktiven nista vedno pokazatelja težav z zmogljivostjo VM. Če VM agresivno uporablja pomnilnik (vsaj dobi dostop do njega), to ne pomeni, da pomnilnika ni dovolj. Namesto tega je priložnost, da vidimo, kaj se dogaja v OS.
Obstaja standardni alarm za uporabo pomnilnika za VM:
V skupni rabi - količina pomnilnika VM, deduplicirana s TPS (znotraj VM ali med VM).
Podeljeno - količino pomnilnika fizičnega gostitelja (KB), ki je bil dodeljen VM. Vključuje Shared.
Porabljeno (Granted – Shared) – količina fizičnega pomnilnika (KB), ki jo VM porabi od gostitelja. Ne vključuje Shared.
Če del pomnilnika VM ni dan iz fizičnega pomnilnika gostitelja, temveč iz izmenjalne datoteke, ali če je pomnilnik vzet iz VM prek balonskega gonilnika, ta količina ni upoštevana v Odobreno in porabljeno.
Visoke odobrene in porabljene vrednosti so popolnoma normalne. Operacijski sistem hipervizorju postopoma jemlje pomnilnik in ga ne vrača. Sčasoma se v aktivno delujočem VM vrednosti teh števcev približajo količini konfiguriranega pomnilnika in tam ostanejo.
nič — količina VM RAM (KB), ki vsebuje ničle. Tak pomnilnik hipervizor šteje za prostega in ga lahko dodeli drugim virtualnim strojem. Ko gostujoči OS nekaj zapiše v ničelni pomnilnik, gre v Consumed in se ne vrne nazaj.
Rezervirani režijski stroški — količino pomnilnika VM (KB), ki jo hipervizor rezervira za delovanje VM. To je majhna količina, vendar mora biti na voljo na gostitelju, sicer se VM ne bo zagnal.
Balon — količina RAM-a (KB), zaseženega VM z gonilnikom Balloon.
Stisnjen - količina RAM-a (KB), ki je bila stisnjena.
Zamenjave - količina RAM-a (KB), ki se je zaradi pomanjkanja fizičnega pomnilnika na strežniku premaknila na disk.
Števci balonov in drugih tehnik za pridobivanje pomnilnika so nič.
Tako je videti graf s števci pomnilnika za normalno delujoč VM s 150 GB RAM-a.
Na spodnjem grafu ima VM očitne težave. Pod grafom lahko vidite, da so bile za ta VM uporabljene vse opisane tehnike za delo z RAM-om. Balon za ta VM je veliko večji od Consumed. Pravzaprav je VM bolj mrtev kot živ.
ESXTOP
Tako kot pri CPE, če želimo hitro oceniti stanje na gostitelju in njegovo dinamiko z intervalom do 2 sekund, moramo uporabiti ESXTOP.
Zaslon ESXTOP s strani Memory se prikliče s tipko "m" in izgleda takole (izbrana so polja B, D, H, J, K, L, O):
Zanimali nas bodo naslednji parametri:
Mem overcommit povpr - povprečna vrednost prezasedenosti pomnilnika na gostitelju za 1, 5 in 15 minut. Če je nad ničlo, potem je to priložnost, da vidite, kaj se dogaja, vendar ne vedno pokazatelj težav.
V vrsticah PMEM/MB и VMKMEM/MB - informacije o fizičnem pomnilniku strežnika in pomnilniku, ki je na voljo VMkernelu. Od zanimivosti tukaj lahko vidite vrednost minfree (v MB), stanje gostitelja v pomnilniku (v našem primeru visoko).
V vrsti NUMA/MB lahko vidite porazdelitev RAM-a po NUMA vozliščih (vtičnicah). V tem primeru je porazdelitev neenakomerna, kar načeloma ni zelo dobro.
Sledi splošna statistika strežnika o tehnikah pridobivanja pomnilnika:
PSHARE/MB so statistike TPS;
ZAMENJAVA/MB — statistika uporabe zamenjave;
ZIP/MB — statistika stiskanja pomnilniške strani;
MEMCTL/MB — Statistika uporabe Balloon Driverja.
Za posamezne virtualne stroje nas bodo morda zanimale naslednje informacije. Imena VM sem skril, da ne bi zmedel občinstva :). Če je metrika ESXTOP podobna števcu v vSphere, podam ustrezen števec.
MEMSZ — količina pomnilnika, konfiguriranega na VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + nedotaknjeno.
DODELITE — Podeljena MB.
TCHD — Aktiven v MB.
MCTL? - ali je gonilnik Balloon Driver nameščen na VM.
MCTLSZ — Balon v MB.
MCTLGT — količina RAM-a (MB), ki jo želi ESXi vzeti iz VM prek Balloon Driver (Memctl Target).
MCTLMAX - največja količina RAM-a (MB), ki jo lahko ESXi vzame iz VM prek balonskega gonilnika.
SWCUR — trenutna količina RAM-a (MB), dodeljenega VM-ju iz izmenjalne datoteke.
S.W.G.T. - količino RAM-a (MB), ki jo želi ESXi dati VM-ju iz datoteke Swap (Swap Target).
Prek ESXTOP si lahko ogledate tudi podrobnejše informacije o topologiji NUMA VM. Če želite to narediti, izberite polja D, G:
MAJHNA – NUMA vozlišča, na katerih se nahaja VM. Tukaj lahko takoj opazite široke vm, ki se ne prilegajo enemu vozlišču NUMA.
NRMEM - koliko megabajtov pomnilnika VM vzame od oddaljenega vozlišča NUMA.
NLMEM - koliko megabajtov pomnilnika VM vzame od lokalnega vozlišča NUMA.
N%L – odstotek pomnilnika VM na lokalnem vozlišču NUMA (če je manj kot 80 %, se lahko pojavijo težave z zmogljivostjo).
Pomnilnik na hipervizorju
Če števci procesorja za hipervizor običajno niso posebej zanimivi, je s pomnilnikom situacija obrnjena. Velika poraba pomnilnika na VM ne pomeni vedno težave z zmogljivostjo, vendar visoka poraba pomnilnika na hipervizorju sproži tehnike upravljanja pomnilnika in povzroči težave z zmogljivostjo v VM. Alarme o uporabi pomnilnika gostitelja je treba spremljati, da preprečite, da bi VM vstopil v Swap.
Prekliči zamenjavo
Če je VM v Swapu, je njegova zmogljivost močno zmanjšana. Sledi baloniranja in stiskanja hitro izginejo, ko se na gostitelju pojavi prosti RAM, vendar se virtualnemu stroju ne mudi vrniti iz zamenjave v strežniški RAM.
Pred ESXi 6.0 je bil edini zanesljiv in hiter način za odstranitev VM iz Swap ponovni zagon (natančneje, izklop/vklop vsebnika). Začenši z ESXi 6.0, čeprav ne povsem uradno, se je pojavil delujoč in zanesljiv način za odstranitev VM iz Swap. Na eni od konferenc sem se lahko pogovarjal z enim od inženirjev VMware, ki je zadolžen za CPU Scheduler. Potrdil je, da je metoda precej delujoča in varna. Tudi z njim po naših izkušnjah ni bilo težav.
Dejanski ukazi za odstranitev VM iz Swap Duncan Epping. Ne bom ponavljal podrobnega opisa, samo navedem primer njegove uporabe. Kot lahko vidite na posnetku zaslona, nekaj časa po izvedbi podanih ukazov Swap izgine na VM.
Nasveti za upravljanje pomnilnika ESXi
Nazadnje je tukaj nekaj nasvetov, ki vam bodo pomagali preprečiti težave z delovanjem VM zaradi RAM-a:
- Izogibajte se preveliki naročnini na pomnilnik v produktivnih gručih. Zaželeno je, da je v gruči vedno ~20-30% prostega pomnilnika, da imata DRS (in skrbnik) manevrski prostor in da VM med selitvijo ne gredo v Swap. Prav tako ne pozabite na rezervo za toleranco napak. Neprijetno je, ko gredo nekateri stroji tudi v Swap, ko en strežnik odpove in se VM znova zažene z uporabo HA.
- V visoko konsolidiranih infrastrukturah NE poskušajte ustvariti navideznih računalnikov z več kot polovico pomnilnika gostitelja. To bo spet pomagalo DRS-u brez težav porazdeliti virtualne stroje po strežnikih gruče. To pravilo seveda ni univerzalno :).
- Bodite pozorni na alarm za uporabo pomnilnika gostitelja.
- Ne pozabite namestiti VMware Tools na VM in ne izklopite Ballooning.
- Razmislite o omogočanju Inter-VM TPS in onemogočanju Large Pages v VDI in testnih okoljih.
- Če ima VM težave z zmogljivostjo, preverite, ali uporablja pomnilnik oddaljenega vozlišča NUMA.
- Čim prej odstranite svoj VM iz Swap! Med drugim, če je VM v Swapu, iz očitnih razlogov trpi sistem za shranjevanje.
To je zame vse glede RAM-a. Spodaj je povezan članek za tiste, ki se želijo poglobiti v podrobnosti. Naslednji članek bo posvečen storadžu.
Uporabne povezave
Vir: www.habr.com