U ovom ćemo članku govoriti o brojačima performansi memorije s izravnim pristupom (RAM) u vSphereu.
Čini se da je s memorijom sve jasnije nego s procesorom: ako VM ima problema s performansama, teško ih je ne primijetiti. Ali ako se pojave, mnogo je teže s njima se nositi. Ali prvo o svemu.
Malo teorije
RAM virtualnih strojeva preuzima se iz memorije poslužitelja na kojem se izvode VM-ovi. Sasvim je očito :). Ako RAM poslužitelja nije dovoljan za sve, ESXi počinje koristiti tehnike vraćanja memorije kako bi optimizirao potrošnju RAM-a. U suprotnom, VM operativni sustavi bi se srušili s greškama pristupa RAM-u.
Koje tehnike koristiti ESXi odlučuje ovisno o opterećenju RAM-a:
Stanje memorije
granica
Djelatnost
visok
400% od minFree
Nakon dostizanja gornje granice, velike memorijske stranice se dijele na male (TPS radi u standardnom načinu rada).
Izbriši
100% od minFree
Velike memorijske stranice su razbijene u male, TPS je prisiljen raditi.
mekan
64% od minFree
TPS + balon
Tvrd
32% od minFree
TPS + Compress + Swap
Nizak
16% od minFree
Sažimanje + Zamjena + Blokiranje
minFree je RAM potreban za rad hipervizora.
Prije ESXi 4.1 uključujući, minFree je bio fiksiran prema zadanim postavkama - 6% RAM-a poslužitelja (postotak se može promijeniti putem opcije Mem.MinFreePct na ESXi). U kasnijim verzijama, zbog povećanja veličine memorije na poslužiteljima, minFree se počeo izračunavati na temelju količine memorije hosta, a ne kao fiksni postotak.
MinFree (zadana) vrijednost izračunava se na sljedeći način:
Postotak memorije rezerviran za minFree
Raspon memorije
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Preostala memorija
Na primjer, za poslužitelj sa 128 GB RAM-a vrijednost MinFree bila bi:
Min. besplatno = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Stvarna vrijednost može se razlikovati za nekoliko stotina MB, ovisi o poslužitelju i RAM-u.
Postotak memorije rezerviran 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 produktivne sastojine samo visoko stanje može smatrati normalnim. Za testne i razvojne stolove, Clear/Soft stanja mogu biti prihvatljiva. Ako je RAM na hostu manji od 64% MinFree, tada VM-ovi koji rade na njemu definitivno imaju problema 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, a završava s Swappingom. Reći ću vam više o njima.
Transparentno dijeljenje stranica (TPS). TPS je, grubo rečeno, deduplikacija memorijskih stranica virtualnog stroja na poslužitelju.
ESXi traži identične stranice RAM-a virtualnog stroja prebrojavanjem i usporedbom hash zbroja stranica i uklanja duplicirane stranice, zamjenjujući ih poveznicama na istu stranicu u fizičkoj memoriji poslužitelja. Kao rezultat toga, potrošnja fizičke memorije je smanjena, a određena prekomjerna pretplata na memoriju može se postići s malo ili bez ikakve degradacije performansi.
Ovaj mehanizam radi samo za memorijske stranice od 4 KB (male stranice). Hipervizor niti ne pokušava dedupirati stranice od 2 MB (velike stranice): šansa da se pronađu identične stranice ove veličine nije velika.
Prema zadanim postavkama, ESXi dodjeljuje memoriju velikim stranicama. Razbijanje velikih stranica na male stranice počinje kada se dosegne Visoki prag stanja i prisilno je kada se dostigne Očisti stanje (pogledajte tablicu stanja hipervizora).
Ako želite da TPS počne raditi bez čekanja da se RAM hosta napuni, u Advanced Options ESXi morate postaviti vrijednost “Mem.AllocGuestLargePage” na 0 (zadano 1). Tada će dodjela velikih memorijskih stranica za virtualne strojeve biti onemogućena.
Od prosinca 2014., u svim izdanjima ESXi-ja, TPS između VM-ova je prema zadanim postavkama onemogućen, budući da je pronađena ranjivost koja teoretski dopušta pristup s jednog VM-a na RAM drugog VM-a. Pojedinosti ovdje. Nisam naišao na informacije o praktičnoj primjeni iskorištavanja TPS ranjivosti.
TPS politika kontrolirana putem napredne opcije “Mem.ShareForceSalting” na ESXi:
0 - Inter-VM TPS. TPS radi za stranice različitih VM-ova;
1 – TPS za VM s istom vrijednošću "sched.mem.pshare.salt" u VMX-u;
2 (zadano) - 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 stolovima. Može se koristiti i za postolja s velikim brojem VM iste vrste. Na primjer, na postoljima s VDI, uštede u fizičkoj memoriji mogu doseći desetke postotaka.
baloniranje sjećanja. Baloniranje više nije tako bezopasna i transparentna tehnika za VM operativni sustav kao TPS. Ali uz pravilnu primjenu, možete živjeti, pa čak i raditi s Ballooningom.
Zajedno s Vmware alatima, poseban upravljački program pod nazivom Balloon Driver (aka vmmemctl) instaliran je na VM. Kada hipervizoru počne ponestajati fizičke memorije i uđe u Soft stanje, ESXi traži od VM-a da povrati neiskorišteni RAM putem ovog Balloon Drivera. Upravljački program zauzvrat radi na razini operativnog sustava i od njega traži slobodnu memoriju. Hipervizor vidi koje je stranice fizičke memorije Balloon Driver zauzeo, preuzima memoriju s virtualnog stroja i vraća je hostu. Nema problema s radom OS-a budući da na razini OS-a memoriju zauzima Balloon Driver. Prema zadanim postavkama Balloon Driver može zauzeti do 65% VM memorije.
Ako VMware Tools nisu instalirani na VM ili je baloniranje onemogućeno (ne preporučujem, ali postoje :), hipervizor se odmah prebacuje na strože tehnike uklanjanja memorije. Zaključak: provjerite jesu li VMware Tools na VM-u.
Rad Balloon Drivera može se provjeriti iz OS-a putem VMware Tools.
kompresija memorije. Ova tehnika se koristi kada ESXi dosegne Hard stanje. Kao što naziv implicira, ESXi pokušava smanjiti 4KB stranicu RAM-a u 2KB i tako osloboditi prostor u fizičkoj memoriji poslužitelja. Ova tehnika značajno povećava vrijeme pristupa sadržaju stranica VM RAM-a, budući da se stranica prvo mora dekomprimirati. Ponekad se sve stranice ne mogu komprimirati i sam proces traje neko vrijeme. Stoga ova tehnika nije vrlo učinkovita u praksi.
zamjena memorije. Nakon kratke faze sažimanja memorije, ESXi će se gotovo neizbježno (ako VM-ovi nisu otišli na druga računala ili se isključili) prebaciti na zamjenu. A ako je ostalo vrlo malo memorije (nisko stanje), hipervizor također prestaje dodjeljivati memorijske stranice VM-u, što može uzrokovati probleme u gostujućem OS-u VM-a.
Evo kako zamjena funkcionira. Kada uključite virtualni stroj, za njega se kreira datoteka s nastavkom .vswp. Po veličini je jednak nerezerviranom RAM-u VM-a: to je razlika između konfigurirane i rezervirane memorije. Kada je zamjena pokrenuta, ESXi učitava memorijske stranice virtualnog stroja u ovu datoteku i počinje raditi s njom umjesto s fizičkom memorijom poslužitelja. Naravno, takva takva "operativna" memorija je nekoliko redova veličine sporija od stvarne, čak i ako .vswp leži na brzoj pohrani.
Za razliku od Ballooning-a, kada se neiskorištene stranice preuzmu iz VM-a, sa Swappingom, stranice koje aktivno koriste OS ili aplikacije unutar VM-a mogu se premjestiti na disk. Kao rezultat toga, performanse VM-a padaju do točke smrzavanja. VM formalno radi i barem se može ispravno onemogućiti iz OS-a. Ako ste strpljivi 😉
Ako su VM otišli u Swap, to je nenormalna situacija, koju je najbolje izbjeći ako je moguće.
Ključni brojači performansi VM memorije
Dakle, došli smo do glavne stvari. Za praćenje stanja memorije u VM-u postoje sljedeći brojači:
Aktivan — prikazuje količinu RAM-a (KB) kojoj je VM dobio pristup u prethodnom razdoblju mjerenja.
Upotreba - isto što i aktivno, ali kao postotak konfiguriranog RAM-a VM-a. Izračunava se pomoću sljedeće formule: aktivna ÷ veličina konfigurirane memorije virtualnog stroja.
Velika upotreba odnosno Aktivno nisu uvijek pokazatelji problema s performansama VM-a. Ako VM agresivno koristi memoriju (bar joj pristupa), to ne znači da nema dovoljno memorije. Umjesto toga, to je prilika da vidite što se događa u OS-u.
Postoji standardni alarm za korištenje memorije za VM:
Zajednička - količina VM RAM-a deduplicirana pomoću TPS-a (unutar VM-a ili između VM-ova).
odobreno - količina fizičke memorije hosta (KB) koja je dana VM-u. Uključuje Shared.
konzumira (Granted - Shared) - količina fizičke memorije (KB) koju VM troši od glavnog računala. Ne uključuje Shared.
Ako dio VM memorije nije dodijeljen iz fizičke memorije glavnog računala, već iz swap datoteke, ili je memorija preuzeta iz VM-a putem Balloon Drivera, taj se iznos ne uzima u obzir u Odobreno i Potrošeno.
Visoke odobrene i potrošene vrijednosti savršeno su normalne. Operativni sustav postupno uzima memoriju od hipervizora i ne vraća je. Tijekom vremena, u aktivnom VM-u, vrijednosti ovih brojača približavaju se količini konfigurirane memorije i tamo ostaju.
nula — količina VM RAM-a (KB), koja sadrži nule. Takvu memoriju hipervizor smatra slobodnom i može se dati drugim virtualnim strojevima. Nakon što je gostujući OS nešto zapisao u nultu memoriju, to ide u Consumed i ne vraća se natrag.
Rezervirani režijski troškovi — količina VM RAM-a (KB) koju hipervizor rezervira za rad VM-a. Ovo je mala količina, ali mora biti dostupna na hostu, inače se VM neće pokrenuti.
Balon — količina RAM-a (KB) oduzeta od VM-a pomoću Balloon Drivera.
komprimirani - količina RAM-a (KB) koja je komprimirana.
Zamijenio - količina RAM-a (KB) koja je, zbog nedostatka fizičke memorije na poslužitelju, premještena na disk.
Brojači balona i drugih tehnika vraćanja memorije su nula.
Ovako izgleda graf s brojačima memorije za normalno radnu VM sa 150 GB RAM-a.
Na donjem grafikonu VM ima očite probleme. Ispod grafa možete vidjeti da su za ovaj VM korištene sve opisane tehnike za rad s RAM-om. Balon za ovaj VM puno je veći od Consumed. Zapravo, VM je više mrtav nego živ.
ESXTOP
Kao i kod CPU-a, ako želimo brzo procijeniti stanje na hostu, kao i njegovu dinamiku s intervalom do 2 sekunde, trebali bismo koristiti ESXTOP.
Ekran ESXTOP od strane Memory poziva se tipkom "m" i izgleda ovako (odabrana su polja B, D, H, J, K, L, O):
Od interesa će nam biti sljedeći parametri:
Mem overcommit prosj - prosječna vrijednost prekomjerne pretplate memorije na hostu za 1, 5 i 15 minuta. Ako je iznad nule, onda je to prilika da vidite što se događa, ali ne uvijek pokazatelj problema.
U redovima PMEM/MB и VMKMEM/MB - informacije o fizičkoj memoriji poslužitelja i memoriji dostupnoj VMkernelu. Od zanimljivosti ovdje možete vidjeti vrijednost minfree (u MB), stanje hosta u memoriji (u našem slučaju, visoko).
U redu NUMA/MB možete vidjeti raspodjelu RAM-a po NUMA čvorovima (utičnicama). U ovom primjeru distribucija je neravnomjerna, što u principu nije baš dobro.
Slijedi opća statistika poslužitelja o tehnikama vraćanja memorije:
PSHARE/MB su TPS statistike;
ZAMJENA/MB — Statistika korištenja zamjene;
ZIP/MB — statistika kompresije memorijske stranice;
MEMCTL/MB — Statistika korištenja Balloon Drivera.
Za pojedinačne virtualne mašine mogle bi nas zanimati sljedeće informacije. Sakrio sam imena VM da ne zbunim publiku :). Ako je metrika ESXTOP slična brojaču u vSphereu, dajem odgovarajući brojač.
MEMSZ — količina memorije konfigurirana na VM-u (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + nedirnuto.
GRANT — Dodijeljena MB.
TCHD — Aktivan u MB.
MCTL? - je li Balloon Driver instaliran na VM.
MCTLSZ — Balon do MB.
MCTLGT — količina RAM-a (MB) koju ESXi želi uzeti od VM-a putem Balloon Drivera (Memctl Target).
MCTLMAX - maksimalnu količinu RAM-a (MB) koju ESXi može uzeti od VM-a putem Balloon Drivera.
SWCUR — trenutna količina RAM-a (MB) dodijeljena VM-u iz Swap datoteke.
S.W.G.T. - količinu RAM-a (MB) koju ESXi želi dati VM-u iz Swap datoteke (Swap Target).
Također, putem ESXTOP-a možete vidjeti detaljnije informacije o NUMA topologiji VM-a. Da biste to učinili, odaberite polja D, G:
MALI – NUMA čvorova na kojima se nalazi VM. Ovdje možete odmah primijetiti široke vm, koje ne stanu na jedan NUMA čvor.
NRMEM - koliko megabajta memorije VM uzima od udaljenog NUMA čvora.
NLMEM - koliko megabajta memorije VM uzima od lokalnog NUMA čvora.
N%L – postotak VM memorije na lokalnom NUMA čvoru (ako je manji od 80%, mogu se pojaviti problemi s performansama).
Memorija na hipervizoru
Ako CPU brojači za hipervizor obično nisu od posebnog interesa, onda je situacija obrnuta s memorijom. Visoka upotreba memorije na VM-u ne ukazuje uvijek na problem s izvedbom, ali velika upotreba memorije na hipervizoru pokreće tehnike upravljanja memorijom i uzrokuje probleme s izvedbom u VM-u. Alarmi korištenja memorije glavnog računala moraju se nadzirati kako bi se spriječilo da VM uđe u Swap.
razmijeniti
Ako je VM u Swapu, njegova izvedba je znatno smanjena. Tragovi Ballooning-a i kompresije brzo nestaju nakon što se na hostu pojavi slobodan RAM, ali virtualni stroj se ne žuri vratiti iz Swap-a u RAM poslužitelja.
Prije ESXi 6.0, jedini pouzdan i brz način za izbacivanje VM-a iz Swapa bio je ponovno pokretanje (da budemo precizniji, isključivanje/uključivanje spremnika). Počevši od ESXi 6.0, iako ne sasvim službeno, pojavio se funkcionalan i pouzdan način uklanjanja VM-a iz Swapa. Na jednoj od konferencija uspio sam razgovarati s jednim od VMware inženjera zaduženim za CPU Scheduler. Potvrdio je da je metoda prilično učinkovita i sigurna. Prema našem iskustvu, ni s njim nije bilo problema.
Stvarne naredbe za uklanjanje VM-a iz Swapa Duncan Epping. Neću ponavljati detaljan opis, samo dajem primjer njegove upotrebe. Kao što možete vidjeti na snimci zaslona, neko vrijeme nakon izvršenja navedenih naredbi, Swap nestaje na VM-u.
Savjeti za upravljanje ESXi memorijom
Na kraju, evo nekoliko savjeta koji će vam pomoći da izbjegnete probleme s performansama VM-a zbog RAM-a:
- Izbjegavajte preveliku pretplatu na memoriju u produktivnim klasterima. Poželjno je uvijek imati ~20-30% slobodne memorije u klasteru kako bi DRS (i administrator) imali prostora za manevar, a VM-ovi ne bi išli u Swap tijekom migracije. Također, ne zaboravite na marginu tolerancije grešaka. Neugodno je kada, kada jedan poslužitelj zakaže i VM se ponovno pokrene pomoću HA, neki od strojeva također odu u Swap.
- U visoko konsolidiranim infrastrukturama, pokušajte NE stvarati VM-ove s više od polovice memorije glavnog računala. Ovo će ponovno pomoći DRS-u da distribuira virtualne strojeve po poslužiteljima klastera bez ikakvih problema. Ovo pravilo, naravno, nije univerzalno :).
- Pripazite na alarm za korištenje memorije glavnog računala.
- Ne zaboravite instalirati VMware Tools na VM i nemojte isključiti Ballooning.
- Razmislite o omogućavanju Inter-VM TPS-a i onemogućavanju velikih stranica u VDI i testnim okruženjima.
- Ako VM ima problema s performansama, provjerite koristi li memoriju s udaljenog NUMA čvora.
- Izvucite svoju VM iz Swapa što je brže moguće! Između ostalog, ako je VM u Swapu, iz očiglednih razloga, pati sustav za pohranu.
To je sve što se mene tiče RAM-a. U nastavku je povezan članak za one koji žele kopati po detaljima. Sljedeći članak bit će posvećen storadzhu.
korisni linkovi
Izvor: www.habr.com