V tem članku bomo govorili o merilnikih zmogljivosti pomnilnika (RAM) v vSphere.
Zdi se, da je s pomnilnikom vse bolj enoznačno kot s procesorjem: če na VM pride do težav z zmogljivostjo, jih je težko spregledati. Če se težave pojavijo, se jih je veliko težje rešiti. A gremo po vrsti.
Nekaj teorije
Pomnilnik virtualnih strojev se jemlje iz pomnilnika strežnika, na katerem delujejo VM-ji. To je povsem očitno :). Če pomnilnika na strežniku ne zadošča za vse potrebne, ESXi začne uporabljati tehnike optimizacije porabe pomnilnika (tehnike pridobivanja pomnilnika). V nasprotnem primeru bi se operacijski sistemi VM zrušili z napakami dostopa do RAM-a.
Katere tehnike bo ESXi uporabil, se odloča glede na obremenitev pomnilnika:
Stanje pomnilnika
Meja
Akcije
Visoko
400 % od minFree
Ko je dosežena zgornja meja, se velike strani pomnilnika razbijejo na manjše (TPS deluje v standardnem načinu).
Počisti
100 % od minFree
Velike strani pomnilnika se razbijejo na manjše, TPS deluje prisilno.
Soft
64 % od minFree
TPS + Balloon
Trda
32 % od minFree
TPS + Compress + Swap
Low
16 % od minFree
Compress + Swap + Block
minFree je pomnilnik, potreben za delovanje hipervizorja.
Do ESXi 4.1 je bil minFree privzeto fiksiran – 6 % od zmogljivosti pomnilnika strežnika (percento se je dalo spremeniti preko možnosti Mem.MinFreePct na ESXi). V novejših različicah se je zaradi rasti količin pomnilnika na strežnikih minFree začelo izračunavati glede na količino pomnilnika gostitelja, ne pa kot fiksna procentualna vrednost.
Vrednost minFree (privzeto) se izračuna na naslednji način:
Procent 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 je minFree naslednja:
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 pomnilnika.
Procent 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 za produktivne stojnice velja, da je normalno stanje le visoko. Za testne in razvojne stojnice so sprejemljiva stanja Clear/Soft. Če je na gostitelju ostalo manj kot 64 % MinFree, imajo VM-ji, ki delujejo na njem, gotovo težave z zmogljivostjo.
V vsakem stanju se uporabljajo določene tehnike za pridobivanje pomnilnika, od TPS, ki praktično ne vpliva na zmogljivost VM, do Swappinga. O njih bom podrobneje spregovoril.
Transparentna delitev strani (TPS). TPS je, preprosto rečeno, deduplikacija strani delovne pomnilnika virtualnih strojov na strežniku.
ESXi išče enake strani delovnega pomnilnika virtualnih strojev, pri čemer izračuna in primerja hash obremenitev strani ter odstrani duplikate strani, jih zamenja z referencami na isto stran v fizičnem pomnilniku strežnika. Tako se zmanjša poraba fizičnega pomnilnika in doseže določena prenova pomnilnika praktično brez izgube zmogljivosti.
Ta mehanizem deluje le za strani pomnilnika velikosti 4 Kb (majhne strani). Hiperkrmilnik niti ne poskuša deduplikirati strani velikosti 2 Mb (velike strani), saj je verjetnost, da bi našel enake strani te velikosti, majhna.
Privzeto ESXi dodeli pomnilnik velikim stranem. Razdelitev velikih strani na male se začne ob doseganju praga stanja High in se zgodi prisilno, ko se doseže stanje Clear (glejte tabelo stanj hipervizorja).
Če pa želite, da TPS začne delovati, ne da bi čakal na napolnitev delovnega pomnilnika gostitelja, v razširjenih možnostih ESXi nastavite vrednost “Mem.AllocGuestLargePage” na 0 (privzeto 1). Tako bo dodeljevanje velikih strani pomnilnika za virtualne stroje onemogočeno.
Od decembra 2014 je v vseh različicah ESXi TPS med VM privzeto onemogočen, ker je bila ugotovljena ranljivost, ki teoretično omogoča dostop do delovnega pomnilnika druge VM iz ene VM. Podrobnosti tukaj. O praktični uporabi ranljivosti TPS nisem zasledil informacij.
Politika TPS se upravlja preko razširjene možnosti “Mem.ShareForceSalting” na ESXi:
0 — Inter-VM TPS. TPS deluje za strani različnih VM;
1 – TPS za VM z enako vrednostjo “sched.mem.pshare.salt” v VMX;
2 (privzeto) – Intra-VM TPS. TPS deluje za strani znotraj VM.
Obvezno je smiselno izklopiti velike strani in omogočiti Inter-VM TPS na testnih platformah. To se lahko uporablja tudi za platforme z veliko enakih VM. Na primer, na platformah z VDI lahko prihranek fizičnega pomnilnika doseže več deset odstotkov.
Pomnilniško baloniranje. Ballooning ni že ni tako nedolžna in prozorna za operacijski sistem VM tehnika, kot je TPS. A ob pravilni uporabi lahko živimo in celo delamo z Ballooningom.
Skupaj z Vmware Tools se na VM namesti poseben gonilnik, imenovan Balloon Driver (tudi vmmemctl). Ko hipervizorju začne primanjkovati fizične pomnilnike in preide v stanje Soft, ESXi prosi VM, da vrne neuporabljeno operativno pomnilnik preko tega Balloon Driverja. Gonilnik na svojo stran deluje na ravni operacijskega sistema in od njega zahteva prost pomnilnik. Hipervizor vidi, katere strani fizičnega pomnilnika je zasedel Balloon Driver, vzame pomnilnik od virtualne naprave in ga vrne gostitelju. Težave z delovanjem OS ne nastanejo, saj je na ravni OS pomnilnik zaseden z Balloon Driverjem. Privzeto Balloon Driver lahko vzame do 65% pomnilnika VM.
Če na VM niso nameščeni VMware Tools ali je Ballooning onemogočen (ne priporočam, a je možno :), hipervizor takoj preide na ostrejše tehnike odvzema pomnilnika. Zaključek: poskrbite, da bodo VMware Tools nameščeni na VM.
Delovanje Balloon Driverja lahko preverite iz OS preko VMware Tools..
Stiskanje pomnilnika. Ta tehnika se uporablja, ko ESXi doseže stanje Hard. Kot pove že ime, ESXi poskuša stisniti 4 Kbyte strani operativne pomnilnika na 2 Kbyte in tako osvoboditi malo prostora v fizičnem pomnilniku strežnika. Ta tehnika znatno poveča čas dostopa do vsebine strani operativne pomnilnika VM, saj je treba stran prej razširiti. Včasih se ne vse strani uspe stisniti in sam postopek traja nekaj časa. Zato ta tehnika v praksi ni zelo učinkovita.
Zamenjava pomnilnika. Po kratkem obdobju stiskanja pomnilnika ESXi skoraj neizogibno (če VM niso odšle na druge gostitelje ali se niso izklopile) preide na zamenjavo. In če pomnilnika zares malo ostane (stanje Low), hipervizor preneha dodeljevati VM strani pomnilnika, kar lahko povzroči težave v gostujočih OS VM.
Tako deluje Swapping. Ko se aktivira virtualni stroj, se ustvari datoteka z razširitvijo .vswp. Njena velikost ustreza nezaščenemu delovnemu pomnilniku VM: to je razlika med konfiguriranim in rezerviranim pomnilnikom. Med delovanjem Swappinga ESXi prenese strani pomnilnika virtualnega stroja v to datoteko in začne delovati z njo namesto s fizičnim pomnilnikom strežnika. Seveda je takšna 'operativna' pomnilnost veliko počasnejša od prave, tudi če .vswp leži na hitrem shranjevanju.
Za razliko od Ballooninga, ko se VM odvzamejo neizkoriščene strani, lahko pri Swappingu na disk preidejo strani, ki jih aktivno uporablja OS ali aplikacije znotraj VM. Posledično se zmogljivost VM zmanjša, vse do zamrznitve. VM formalno deluje in jo je vsaj mogoče pravilno izklopiti iz OS. Če boste potrpežljivi 😉
Če je VM prešla v Swap — je to izredna situacija, ki ji je bolje preprečiti, kolikor je mogoče.
Glavni kazalniki zmogljivosti pomnilnika virtualnega stroja
Pravkar smo prišli do glavnega. Za spremljanje stanja pomnilnika v VM obstajajo naslednji kazalniki:
Active — prikazuje obseg delovnega pomnilnika (KB), do katerega je VM imela dostop v prejšnjem merilnem obdobju.
Usage — enako kot Active, vendar v odstotkih od konfiguriranega delovnega pomnilnika VM. Izračuna se po naslednji formuli: active ÷ velikost konfiguriranega pomnilnika virtualnega stroja.
Visok Usage in Active nista nujno pokazatelja težav z zmogljivostjo VM. Če VM agresivno uporablja pomnilnik (vsaj dostopa do njega), to ne pomeni, da pomnilnik primanjkuje. Raje je to razlog, da pogledate, kaj se dogaja v OS.
Obstaja standardni Alarm za Memory Usage za VM:
Skupna — obseg delovnega pomnilnika VM, dedupliciran s pomočjo TPS (znotraj VM ali med VM).
Granted — obseg fizičnega pomnilnika gostitelja (KB), ki je bil dodeljen VM. Vključuje Shared.
Consumed (Granted — Shared) — obseg fizičnega pomnilnika (KB), ki ga VM porabi s gostitelja. Ne vključuje Shared.
Če del pomnilnika VM ne izhaja iz fizičnega pomnilnika gostitelja, ampak iz swap datoteke ali je pomnilnik odvzet VM preko Balloon Driverja, ta obseg ni upoštevan v Granted in Consumed.
Visoka vrednost Granted in Consumed je povsem normalna. Operacijski sistem postopoma odvzema spomin hipervizorju in ga ne vrača. Sčasoma se pri aktivni VM vrednosti teh merilnikov približajo prostornini konfigurirane pomnilnika in tam ostanejo.
Zero — količina delovnega pomnilnika VM (Kbyte), ki vsebuje ničle. Takšen pomnilnik hipervizor obravnava kot prost in ga lahko dodeli drugim virtualnim strojema. Ko operacijski sistem gostitelja zapiše kaj v ponastavljeni pomnilnik, preide v Consumed in se nazaj ne vrne.
Reserved Overhead — količina delovnega pomnilnika VM (Kbyte), ki jo hipervizor rezervira za delovanje VM. To je majhna količina, vendar mora obstajati na gostitelju, sicer VM ne bo zagnan.
Balloon — količina delovnega pomnilnika (Kbyte), ki je bila odvzeta VM s pomočjo Balloon Driverja.
Compressed — količina delovnega pomnilnika (Kbyte), ki jo je uspelo stisniti.
Swapped — količina delovnega pomnilnika (Kbyte), ki je zaradi pomanjkanja fizičnega pomnilnika na strežniku prešla na disk.
Balloon in ostale merilnike tehnik vračanja pomnilnika so enake nič.
Tako izgleda graf s številkami Memory normalno delujoče VM s 150 GB delovnega pomnilnika.
Na grafu spodaj ima VM očitne težave. Pod grafom je razvidno, da so za to VM bile uporabljene vse opisane tehnike dela z delovnim pomnilnikom. Balloon za to VM je bistveno večji od Consumed. Dejansko je VM bolj mrtva kot živa.
ESXTOP
Kot pri CPU, če želimo hitro oceniti situacijo na gostitelju in njeno dinamiko s časovnim intervalom do 2 sekund, je smiselno uporabiti ESXTOP.
Zaslon ESXTOP za Memory se aktivira s tipko 'm' in izgleda takole (izbrane so polja B, D, H, J, K, L, O):
Zanimali nas bodo naslednji parametri:
Mem overcommit avg — povprečna vrednost preobremenitve pomnilnika na gostitelju v zadnjem 1, 5 in 15 minutah. Če je višja od nič, je to razlog za razmislek o tem, kaj se dogaja, vendar ne vedno dokazuje obstoj težav.
V vrsticah PMEM/MB in VMKMEM/MB — informacije o fizičnem pomnilniku strežnika in pomnilniku, dostopnem VMkernelu. Interesantno je videti vrednost minfree (v MB), stanje gostitelja glede pomnilnika (v našem primeru, visoko).
V vrstici NUMA/MB lahko vidimo razporeditev delovnega pomnilnika po NUMA vozlih (soketih). V tem primeru razporeditev ni enakomerna, kar načeloma ni dobro.
Nasledije daje opšte statistike o serveru o tehnikama vraćanja memorije:
PSHARE/MB — to je TPS statistika;
SWAP/MB — statistika korišćenja Swap-a;
ZIP/MB — statistika kompresije stranica memorije;
MEMCTL/MB — statistika korišćenja Balloon Driver-a.
Za svaku VM, možemo biti zainteresovani za sledeće informacije. Imena VM sam sakrio, kako ne bih zbunio publiku :). Ako je metrika ESXTOP slična brojaču u vSphere, navodim odgovarajući brojač.
MEMSZ — ukupna memorija, konfigurirana za VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Granted u MB.
TCHD — Active u MB.
MCTL? — da li je na VM-u postavljen Balloon Driver.
MCTLSZ — Balloon u MB.
MCTLGT — količina RAM-a (MB), koju ESXi želi da oduzme od VM-a putem Balloon Driver-a (Memctl Target).
MCTLMAX — maksimalna količina RAM-a (MB), koju ESXi može oduzeti od VM-a putem Balloon Driver-a.
SWCUR — trenutna količina RAM-a (MB), koja je data VM-u iz Swap fajla.
SWGT — količina RAM-a (MB), koju ESXi želi da daje VM-u iz Swap fajla (Swap Target).
Takođe, putem ESXTOP-a možete pogledati detaljnije informacije o NUMA topologiji VM-a. Za to treba odabrati polja D,G:
NHN – NUMA čvorovi na kojima je smešten VM. Ovde se odmah mogu primetiti široki VM-ovi, koji ne mogu stati na jedan NUMA čvor.
NRMEM – koliko megabajta memorije VM uzima sa udaljenog NUMA čvora.
NLMEM – koliko megabajta memorije VM uzima sa lokalnog NUMA čvora.
N%L – procenat memorije VM na lokalnom NUMA čvoru (ako je manje od 80% — mogu se javiti problemi sa performansama).
Memorija na hipervizoru
Ako CPU brojači na hipervizoru obično ne predstavljaju poseban interes, situacija sa memorijom je suprotna. Visoka potrošnja memorije na VM-u ne znači uvek da postoji problem sa performansama, ali visoka potrošnja memorije na hipervizoru pokreće tehnike upravljanja memorijom i izaziva probleme sa performansama VM-a. Potrebno je pratiti alarmirane Host Memory Usage i ne dozvoliti da VM dođe u Swap.
Unswap
Ako VM dođe u Swap, njena performansa se značajno smanjuje. Tragovi Ballooning-a i kompresije brzo nestaju nakon što se slobodna RAM na hostu pojavi, ali vraćanje iz Swapa u RAM servera virtuelna mašina ne žuri.
Do različice ESXi 6.0 je bil edini zanesljiv in hiter način za izhod VM iz Swap-a ponovno zagon (natančneje izklop/ vklop kontejnerja). Začenši z ESXi 6.0 se je pojavil še ne popolnoma uraden, a delujoč in zanesljiv način za izhod VM iz Swap-a. Na eni izmed konferenc sem imel priložnost govoriti z enim od inženirjev VMware, ki je odgovoren za CPU Scheduler. Potrdil je, da je metoda povsem delujoča in varna. V našem primeru nismo imeli težav z njo.
Dejansko ukaz za izhod VM iz Swap-a Duncan Epping. Ne bom ponavljal podrobnega opisa, samo navedel bom primer njene uporabe. Kot je razvidno na posnetku zaslona, po določenem času po izvedbi navedenega ukaza Swap na VM izgine.
Nasveti za upravljanje z operativno pomnilnikom v ESXi
Na koncu bom navedel nekaj nasvetov, ki vam bodo pomagali preprečiti težave s hitrostjo VM zaradi operativne pomnilnika:
- Ne dovolite preseganja po operativni pomnilniki v produkcijskih grozdih. Priporočljivo je, da imate vedno ~20-30% prostega pomnilnika v grozdu, da ima DRS (in administrator) prostor za manevriranje, in da med migracijo VM ne bi šli v Swap. Poleg tega ne pozabite na rezervo za odpornost na napake. Ni prijetno, ko pri okvari enega strežnika in ponovnem zagonu VM s pomočjo HA del dela strojev še gre v Swap.
- V infrastrukturah z visoko konsolidacijo se trudite NE ustvariti VM z več pomnilnika kot polovico pomnilnika gostitelja. To ponovno pomaga DRS, da brez težav porazdeli virtualne stroje po strežnikih grozda. To pravilo, seveda, ni univerzalno :).
- Spremljajte alarma za uporabo pomnilnika gostitelja.
- Ne pozabite namestiti VMware Tools na VM in ne izklapljajte Ballooninga.
- Razmislite o možnosti vključitve Inter-VM TPS in izklopa Large Pages v okoljih z VDI in testnih okoljih.
- Če VM doživlja težave s hitrostjo, preverite, ali uporablja pomnilnik z oddaljene NUMA-node.
- Izvajajte VM iz Swap-a čim hitreje! Poleg vsega, če je VM v Swap-u, očitno trpi tudi SHR.
Tukaj je vse glede operativne pomnilnika. Spodaj so članki na to temo za tiste, ki želijo poglobiti podrobnosti. Naslednji članek bo posvečen shranjevanju.
Koristne poveznice
Izvor: habr.com
