U ovom članku govorimo o pokazateljima performansi radne memorije (RAM) u vSphere.
Čini se da je s memorijom sve jasnije nego s procesorom: ako na VM-ovima dođe do problema s performansama, teško ih je ne primijetiti. No, kada se pojave, mnogo je teže riješiti ih. Ali idemo redom.
Malo teorije
Radna memorija virtualnih mašina dolazi iz memorije poslužitelja na kojem su VM-ovi pokrenuti. To je sasvim očito :). Ako radne memorije poslužitelja nije dovoljno za sve koji je zahtijevaju, ESXi počinje primjenjivati tehnike optimizacije potrošnje radne memorije (tehnike povrata memorije). Inače bi operativni sustavi VM-a padali s greškama pristupa RAM-u.
Koje tehnike primijeniti ESXi odlučuje na temelju opterećenja radne memorije:
Stanje memorije
Granica
Radnje
Visoko
400% od minFree
Nakon dostizanja gornje granice, velike stranice memorije se razbijaju na male (TPS radi u standardnom načinu rada).
Očistiti
100% od minFree
Velike stranice memorije se razbijaju na male, TPS radi prisilno.
Soft
64% od minFree
TPS + Balloon
Hard
32% od minFree
TPS + Compress + Swap
Nisko
16% od minFree
Compress + Swap + Block
minFree je radna memorija potrebna za rad hipervizora.
Do ESXi 4.1 uključivo minFree je po zadanom bio fiksiran — 6% od volumena radne memorije poslužitelja (postotak se mogao promijeniti putem opcije Mem.MinFreePct na ESXi). U novijim verzijama zbog rasta volumena memorije na poslužiteljima, minFree se počelo izračunavati na temelju volumena memorije domaćina, a ne kao fiksna postotna vrijednost.
Vrijednost minFree (po zadanom) izračunava se na sljedeći način:
Postotak memorije rezervirane za minFree
Raspon memorije
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Preostala memorija
Na primjer, za poslužitelj s 128 GB RAM-a, vrijednost MinFree bit će ovakva:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Stvarna vrijednost može se razlikovati za nekoliko stotina MB, ovisno o poslužitelju i radnoj memoriji.
Postotak memorije rezervirane za minFree
Raspon memorije
Vrijednost 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%
Preostala memorija (100 GB)
1024 MB
Obično se za produkcijske postavke samo stanje High može smatrati normalnim. Za postavke za testiranje i razvoj, prihvatljiva mogu biti stanja Clear/Soft. Ako je na hostu ostalo manje od 64% MinFree, tada će VM-ovi koji na njemu rade sigurno pokazivati probleme s performansama.
U svakom stanju primjenjuju se određene tehnike vraćanja memorije, počevši od TPS-a, koji praktički ne utječe na performanse VM-a, do swappinga. O njima ću govoriti detaljnije.
Transparent Page Sharing (TPS). TPS je, pojednostavljeno, dedupliciranje stranica radne memorije virtualnih mašina na serveru.
ESXi traži identične stranice radne memorije virtualnih mašina uspoređujući i poredeći hash vrijednosti stranica, a zatim uklanja duplikate stranica zamjenjujući ih referencama na istu stranicu u fizičkoj memoriji servera. Kao rezultat, potrošnja fizičke memorije se smanjuje i može se postići određena prezahtijevanja memorije praktički bez smanjenja performansi.
Ovaj mehanizam radi samo za stranice memorije veličine 4 KB (male stranice). Hipervizor ne pokušava deduplicirati stranice veličine 2 MB (velike stranice) jer je vjerojatnost pronalaska identičnih stranica te veličine mala.
Prema zadanim postavkama, ESXi dodjeljuje memoriju velikim stranicama. Razdvajanje velikih stranica na male počinje kada se dostigne prag stanja High i događa se prisilno kada se dostigne stanje Clear (vidi tablicu stanja hipervizora).
Ako želite da TPS počne raditi bez čekanja na ispunjenje radne memorije hosta, trebate postaviti vrijednost “Mem.AllocGuestLargePage” na 0 (prema zadanim postavkama 1). Tada će dodjeljivanje velikih stranica memorije za virtualne mašine biti onemogućeno.
Od prosinca 2014. u svim izdanjima ESXi, TPS između VM-a je prema zadanim postavkama isključen, jer je pronađena ranjivost koja teoretski omogućava pristup radnoj memoriji jedne VM kroz drugu VM. Detalji ovdje. Informacije o praktičnoj realizaciji iskorištavanja ranjivosti TPS nisam nalazio.
Politika TPS kontrolira se preko napredne opcije “Mem.ShareForceSalting” na ESXi:
0 — Inter-VM TPS. TPS radi za stranice različitih VM-a;
1 – TPS za VM s istom vrijednošću “sched.mem.pshare.salt” u VMX-u;
2 (prema zadanim postavkama) – Intra-VM TPS. TPS radi za stranice unutar VM-a.
Definitivno ima smisla isključiti velike stranice i uključiti Inter-VM TPS na testnim okruženjima. Također se može koristiti za okruženja s velikim brojem sličnih VM-a. Na primjer, na okruženjima s VDI, ušteda fizičke memorije može doseći desetke posto.
Memory Ballooning. Ballooning više nije toliko bezopasan i proziran tehnika za operacijski sustav VM kao TPS. Međutim, uz pravilnu primjenu, Ballooning može biti funkcionalan i čak koristan.
Uz VMware Tools na VM-u instalira se posebni upravljački program poznat kao Balloon Driver (također vmmemctl). Kada hipervizoru ponestane fizičke memorije i pređe u stanje Soft, ESXi traži od VM-a da vrati neiskorištenu RAM putem ovog Balloon Drivera. Upravljački program, s druge strane, radi na razini operacijskog sustava i traži slobodnu memoriju od njega. Hipervizor vidi koje stranice fizičke memorije je zauzeo Balloon Driver, uzima memoriju od virtualne mašine i vraća je hostu. Problemi s radom OS-a se ne javljaju, jer je na razini OS-a memorija zauzeta od strane Balloon Drivera. Prema zadanim postavkama, Balloon Driver može uzeti do 65% memorije VM-a.
Ako na VM-u nisu instalirani VMware Tools ili je Ballooning isključen (ne preporučujem, ali postoji :), hipervizor odmah prelazi na rigorozniju tehniku uzimanja memorije. Zaključak: pazite da VMware Tools budu prisutni na VM-u.
Rad Balloon Drivera može se provjeriti iz OS-a putem VMware Tools.
Memory Compression. Ova tehnika se primjenjuje kada ESXi dođe do stanja Hard. Kao što naziv sugerira, ESXi pokušava komprimirati 4 KB stranice RAM-a na 2 KB, čime se oslobađa malo prostora u fizičkoj memoriji servera. Ova tehnika značajno povećava vrijeme pristupa sadržaju stranica RAM-a VM-a, jer je potrebno prvo dekomprimirati stranicu. Ponekad nije moguće komprimirati sve stranice, a sam proces traje određeno vrijeme. Stoga ova tehnika u praksi nije vrlo učinkovita.
Memory Swapping. Nakon kratke faze Memory Compression, ESXi praktički neizbježno (osim ako VM-i nisu prebačeni na druge hostove ili isključeni) prelazi na Swapping. A ako ostane vrlo malo memorije (stanje Low), hipervizor također prestaje dodjeljivati VM-ima stranice memorije, što može izazvati probleme u gostujućim OS-ima VM-a.
Evo kako radi Swapping. Kada se uključuje virtualna mašina, za nju se kreira datoteka s ekstenzijom .vswp. Po veličini je jednaka nerezerviranoj radnoj memoriji VM-a: to je razlika između konfigurirane i rezervirane memorije. Kada je Swapping aktivan, ESXi premješta stranice memorije virtualne mašine u ovu datoteku i počinje raditi s njom umjesto s fizičkom memorijom poslužitelja. Naravno, takva „radna“ memorija je nekoliko puta sporija od prave, čak i ako se .vswp nalazi na brzom pohranu.
Za razliku od Ballooninga, kada VM oduzima neiskorištene stranice, prilikom Swappinga na disk mogu preći stranice koje aktivno koristi OS ili aplikacije unutar VM-a. Kao rezultat, performanse VM-a naglo opadaju, čak do zastoja. VM formalno radi i može se ispravno isključiti iz OS-a. Ako budete strpljivi 😉
Ako su VM-ovi prešli u Swap — to je nepravilna situacija koju je najbolje izbjeći kada god je to moguće.
Glavni pokazatelji performansi memorije virtualne mašine
Evo, stigli smo do glavnog. Za praćenje statusa memorije u VM-u postoje sljedeći pokazatelji:
Aktivno — pokazuje količinu radne memorije (KB) kojoj je VM imala pristup u prethodnom mjerodavnom razdoblju.
Korištenje — isto kao Aktivno, ali u postocima od konfigurirane radne memorije VM-a. Izračunava se prema sljedećoj formuli: active ÷ virtual machine configured memory size.
Visok Usage i Aktivno, prema tome, ne ukazuju uvijek na probleme s performansama VM-a. Ako VM agresivno koristi memoriju (barem, ima pristup), to ne znači da joj nedostaje memorije. Radije je to prilika da provjerite što se događa unutar OS-a.
Postoji standardni Alarm za Korištenje Memorije za VM:
Dijeljeni — količina radne memorije VM-a, deduplirane pomoću TPS (unutar VM-a ili između VM-ova).
Odobreno — količina fizičke memorije poslužitelja (KB), koja je dodijeljena VM-u. Uključuje Shared.
Potrošeno (Odobreno — Shared) — količina fizičke memorije (KB) koju VM troši s poslužitelja. Ne uključuje Shared.
Ako dio memorije VM-a dolazi ne iz fizičke memorije poslužitelja, već iz swap datoteke ili je memorija oduzeta od VM-a putem Balloon Driver-a, ta količina se ne uzima u obzir u Odobreno i Potrošeno.
Visoke vrijednosti Granted i Consumed su potpuno normalne. Operativni sustav postupno uzima memoriju od hipervizora i ne vraća je natrag. S vremenom, kod aktivne VM, vrijednosti ovih brojila se približavaju volumenu konfigurirane memorije i tamo ostaju.
Nula — volumen radne memorije VM (KB), koji sadrži nule. Ova memorija se smatra slobodnom od strane hipervizora i može se dodijeliti drugim virtualnim strojevima. Nakon što operativni sustav gosta zapiše nešto u nulti memoriju, prelazi u Consumed i više se ne vraća.
Reserved Overhead — volumen radne memorije VM (KB) rezerviran od strane hipervizora za rad VM. To je mali volumen, ali mora biti prisutan na hostu, inače VM neće krenuti.
Balloon — volumen radne memorije (KB), koji je oduzet od VM putem Balloon Drivera.
Compressed — volumen radne memorije (KB) koji je uspjelo komprimirati.
Swapped — volumen radne memorije (KB) koja je, zbog nedostatka fizičke memorije na serveru, prešla na disk.
Balloon i ostali brojitelji tehnika povrata memorije su jednaki nuli.
Ovako izgleda grafikon s brojiteljima normalno radeće VM s 150 GB radne memorije.
Na grafu ispod, VM ima jasne probleme. Ispod grafa, vidi se da su za ovu VM korištene sve opisane tehnike rada s radnom memorijom. Balloon za ovu VM je puno veći od Consumed. U praksi, VM je više mrtva nego živa.
ESXTOP
Kao i s CPU-om, ako želimo brzo procijeniti situaciju na hostu, kao i njenu dinamiku u intervalu do 2 sekunde, vrijedi koristiti ESXTOP.
Ekran ESXTOP za Memoriju poziva se tipkom „m“ i izgleda ovako (odabrana polja B,D,H,J,K,L,O):
Interesantni za nas bit će sljedeći parametri:
Mem overcommit avg — prosječna vrijednost prekomjerno dodijeljene memorije na hostu tijekom 1, 5 i 15 minuta. Ako je iznad nule, to je razlog da provjerimo što se događa, no to ne mora uvijek značiti prisutnost problema.
U redovima PMEM/MB i VMKMEM/MB — informacije o fizičkoj memoriji servera i memoriji dostupnoj VMkernelu. Od zanimljivosti ovdje možemo vidjeti vrijednost minfree (u MB), stanje hosta prema memoriji (u našem slučaju, visoko).
U retku NUMA/MB možemo vidjeti raspodjelu radne memorije po NUMA čvorovima (socketima). U ovom primjeru, raspodjela nije ravnomjerna, što u načelu nije dobro.
Dalje se nalazi opća statistika poslužitelja o tehnikama povrata memorije:
PSHARE/MB — to je statistika TPS;
SWAP/MB — statistika korištenja Swap-a;
ZIP/MB — statistika kompresije memorijske stranice;
MEMCTL/MB — statistika korištenja Balloon Driver-a.
Može nas zanimati sljedeća informacija o pojedinačnim VM-ovima. Imena VM-ova sam sakrio kako ne bih zbunio publiku :). Ako je ESXTOP metriku moguće usporediti s brojačem u vSphere, navodim odgovarajući brojač.
MEMSZ — količina memorije konfigurirane na VM-u (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT — Granted u megabajtima.
TCHD — Active u megabajtima.
MCTL? — je li Balloon Driver postavljen na VM-u.
MCTLSZ — Balloon u megabajtima.
MCTLGT — količina RAM-a (MB) koju ESXi želi uzeti od VM-a putem Balloon Driver-a (Memctl Target).
MCTLMAX — maksimalna količina RAM-a (MB) koju ESXi može uzeti od VM-a putem Balloon Driver-a.
SWCUR — trenutna količina RAM-a (MB) dodijeljena VM-u iz Swap datoteke.
SWGT — količina RAM-a (MB) koju ESXi želi dodijeliti VM-u iz Swap datoteke (Swap Target).
Također putem ESXTOP-a može se pogledati detaljnije informacije o NUMA topologiji VM-a. Za to je potrebno odabrati polja D,G:
NHN – NUMA čvorovi na kojima se nalaze VM-ovi. Ovdje se odmah može primijetiti wide VM, koji ne staje na jedan NUMA čvor.
NRMEM – koliko megabajta memorije VM uzima s udaljenog NUMA čvora.
NLMEM – koliko megabajta memorije VM uzima s lokalnog NUMA čvora.
N%L – postotak memorije VM na lokalnom NUMA čvoru (ako je manje od 80% — mogu nastati problemi s performansama).
Memorija na hipervizoru
Ako brojači CPU-a na hipervizoru obično ne predstavljaju posebnu zanimljivost, situacija s memorijom je obrnuta. Visoka upotreba memorije na VM-u ne govori uvijek o prisutnosti problema s performansama, ali visoka upotreba memorije na hipervizoru pokreće tehnike upravljanja memorijom i uzrokuje probleme s performansama VM-a. Treba pratiti alarme Host Memory Usage i ne dopustiti da VM pređe u Swap.
Unswap
Ako VM završi u Swapu, njezina se performansa drastično smanjuje. Tragovi Ballooning-a i kompresije brzo nestaju nakon što se na hostu pojavi slobodna RAM, ali vraćanje iz Swapa u RAM poslužitelja VM-u ne ide lako.
Do verzije ESXi 6.0 jedini pouzdani i brzi način za izbacivanje VM iz Swap-a bilo je ponovno pokretanje (preciznije, isključivanje/uključivanje kontejnera). Počevši od ESXi 6.0 pojavio se, iako ne sasvim službeni, ali funkcionalan i pouzdan način za izbacivanje VM iz Swap-a. Na jednoj od konferencija sam imao priliku razgovarati s jednim od inženjera VMware-a zaduženim za CPU Scheduler. Potvrdio je da je taj način sasvim funkcionalan i siguran. U našem iskustvu nismo primijetili nikakve probleme s njim.
Ukratko, komande za izbacivanje VM iz Swap-a Duncan Epping. Neću ponavljati detaljan opis, samo ću dati primjer njenog korištenja. Kao što se može vidjeti na zaslonu, nakon određenog vremena nakon izvršavanja navedene komande, Swap na VM nestaje.
Savjeti za upravljanje RAM-om na ESXi
Na kraju ću navesti nekoliko savjeta koji će vam pomoći da izbjegnete probleme s performansama VM zbog RAM-a:
- Nemojte dopustiti prekomjernu opskrbu RAM-a u produkcijskim klastrima. Preporučljivo je uvijek imati ~20-30% slobodne memorije u klasteru, kako bi DRS (i administrator) imali prostora za manevar, i prilikom migracije VM-a kako ne bi otišli u Swap. Također ne zaboravite na rezervu za otpornost na kvarove. Neugodno je kada prilikom kvara jednog servera i ponovnog pokretanja VM-a putem HA dio mašina također ode u Swap.
- U infrastrukturnim okruženjima s visokom konsolidacijom pokušavajte NE stvarati VM s memorijom većom od polovine memorije hosta. To će opet pomoći DRS-u da bez problema raspodjeli virtualne mašine po serverima klastera. Ovo pravilo, naravno, nije univerzalno :).
- Pratite Alarm o korištenju memorije hosta.
- Ne zaboravite instalirati VMware Tools na VM i ne isključujte Ballooning.
- Razmotrite mogućnost uključivanja Inter-VM TPS i isključivanja Large Pages u VDI okruženjima i testnim okruženjima.
- Ako VM ima problema s performansama, provjerite koristi li memoriju s udaljenog NUMA čvora.
- Izbacite VM iz Swap-a što je brže moguće! Osim svega, ako je VM u Swap-u, iz očitih razloga pati SAN.
To je sve o RAM-u za sada. Ispod su članci na temu za one koji žele dublje ući u detalje. Sljedeći članak bit će posvećen pohranama.
Koristitne veze
Izvor: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish