Në këtë artikull do të flasim për numëruesit e performancës së kujtesës me akses të rastësishëm (RAM) në vSphere.
Duket se me kujtesën gjithçka është më e qartë se sa me procesorin: nëse shfaqen probleme të performancës në një VM, është e vështirë të mos i vini re. Por nëse shfaqen, është shumë më e vështirë të përballesh me to. Por gjërat e para së pari.
Pak teori
RAM-i i makinave virtuale merret nga memoria e serverit në të cilin funksionojnë VM-të. Kjo është mjaft e qartë :). Nëse RAM-i i serverit nuk është i mjaftueshëm për të gjithë, ESXi fillon të përdorë teknikat e rikuperimit të memories. Përndryshe, sistemet operative VM do të rrëzoheshin me gabime të aksesit në RAM.
ESXi vendos se cilat teknika do të përdorë në varësi të ngarkesës së RAM-it:
Statusi i memories
kufi
Aktivitet
i lartë
400% e min Falas
Pas arritjes së kufirit të sipërm, faqet e memories së madhe ndahen në të vogla (TPS funksionon në modalitetin standard).
Qartë
100% e min Falas
Faqet e mëdha të memories ndahen në të vogla, TPS është e detyruar.
Butë
64% e min Falas
TPS + Balon
I vështirë
32% e min Falas
TPS + Kompresim + Ndërrim
ulët
16% e min Falas
Kompresoni + Ndërro + Blloko
MinFree është RAM-i i nevojshëm për funksionimin e hipervizorit.
Deri në ESXi 4.1 përfshirëse, minFree ishte fiksuar si parazgjedhje - 6% e RAM-it të serverit (përqindja mund të ndryshohet nëpërmjet opsionit Mem.MinFreePct në ESXi). Në versionet e mëvonshme, për shkak të rritjes së kujtesës në serverë, minFree filloi të llogaritet në bazë të sasisë së kujtesës së hostit, dhe jo si një vlerë fikse në përqindje.
Vlera minFree (e parazgjedhur) llogaritet si më poshtë:
Përqindja e kujtesës e rezervuar për minFree
Gama e memories
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Kujtesa e mbetur
Për shembull, për një server me 128 GB RAM, vlera MinFree do të jetë si më poshtë:
Min Falas = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Vlera aktuale mund të ndryshojë me disa qindra MB, në varësi të serverit dhe RAM-it.
Përqindja e kujtesës e rezervuar për minFree
Gama e memories
Vlera për 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Kujtesa e mbetur (100 GB)
1024 MB
Në mënyrë tipike, për stendat prodhuese, vetëm gjendja e Lartë mund të konsiderohet normale. Për grupet e testimit dhe zhvillimit, gjendjet e qarta/të buta mund të jenë të pranueshme. Nëse RAM-i në host është më pak se 64% MinFree, atëherë VM-të që funksionojnë në të po përjetojnë patjetër probleme të performancës.
Në çdo gjendje, përdoren teknika të caktuara të rikuperimit të memories, duke filluar nga TPS, e cila praktikisht nuk ka asnjë efekt në performancën e VM-së, deri te Swapping. Unë do t'ju tregoj më shumë rreth tyre.
Ndarja e faqeve transparente (TPS). TPS është, përafërsisht, heqja e dyfishimit të faqeve RAM të makinave virtuale në server.
ESXi kërkon për faqe identike RAM të makinës virtuale duke numëruar dhe krahasuar shumën hash të faqeve dhe heq faqet e kopjuara, duke i zëvendësuar ato me referenca në të njëjtën faqe në kujtesën fizike të serverit. Si rezultat, konsumi i memories fizike zvogëlohet dhe mund të arrihet një mbi-abonim i kujtesës pa pothuajse asnjë ndikim në performancë.
Ky mekanizëm funksionon vetëm për faqet e kujtesës me madhësi 4 KB (faqe të vogla). Hipervizori as që përpiqet të heqë faqet me madhësi 2 MB (faqe të mëdha): mundësia për të gjetur faqe identike të kësaj madhësie nuk është e madhe.
Si parazgjedhje, ESXi shpërndan memorie në faqe të mëdha. Ndarja e faqeve të mëdha në faqe të vogla fillon kur arrihet pragu i gjendjes së lartë dhe detyrohet kur arrihet gjendja Clear (shih tabelën e gjendjes së hipervizorit).
Nëse dëshironi që TPS të fillojë të punojë pa pritur që RAM-i pritës të mbushet, duhet të vendosni vlerën në Opsionet e Avancuara ESXi "Mem.AllocGuestLargePage" në 0 (parazgjedhja 1). Pastaj shpërndarja e faqeve të memories së madhe për makinat virtuale do të çaktivizohet.
Që nga dhjetori 2014, në të gjitha lëshimet e ESXi, TPS midis VM-ve është i çaktivizuar si parazgjedhje, pasi u gjet një cenueshmëri që teorikisht lejon një VM të aksesojë RAM-in e një VM tjetër. Detajet këtu. Nuk kam hasur në informacione në lidhje me zbatimin praktik të shfrytëzimit të cenueshmërisë së TPS.
Politika TPS kontrollohet nëpërmjet opsionit të avancuar "Mem.ShareForceSalting" në ESXi:
0 - Inter-VM TPS. TPS funksionon për faqet e VM-ve të ndryshme;
1 – TPS për VM me të njëjtën vlerë “sched.mem.pshare.salt” në VMX;
2 (e parazgjedhur) – TPS Intra-VM. TPS funksionon për faqet brenda një VM.
Padyshim që ka kuptim të çaktivizoni faqet e mëdha dhe të aktivizoni Inter-VM TPS në stolat e testimit. Kjo mund të përdoret gjithashtu për stendat me një numër të madh të VM-ve të ngjashme. Për shembull, në stendat me VDI, kursimet në kujtesën fizike mund të arrijnë dhjetëra përqind.
Balloon kujtim. Ballooning nuk është më një teknikë aq e padëmshme dhe transparente për sistemin operativ VM si TPS. Por nëse përdoret si duhet, ju mund të jetoni dhe madje të punoni me Balooning.
Së bashku me Vmware Tools, një drejtues i veçantë i quajtur Balloon Driver (aka vmmemctl) është instaluar në VM. Kur hipervizori fillon t'i mbarojë memoria fizike dhe hyn në gjendjen Soft, ESXi i kërkon VM-së të rimarrë RAM-in e papërdorur përmes këtij Drejtuesi të Balloon. Drejtuesi, nga ana tjetër, punon në nivelin e sistemit operativ dhe kërkon memorie të lirë prej tij. Hipervizori shikon se cilat faqe të memories fizike ka zënë drejtuesi i balonit, merr memorie nga makina virtuale dhe ia kthen hostit. Nuk ka probleme me funksionimin e sistemit operativ, pasi në nivelin OS memoria është e zënë nga drejtuesi i balonit. Si parazgjedhje, Balloon Driver mund të marrë deri në 65% të kujtesës VM.
Nëse VMware Tools nuk është i instaluar në VM ose Balooning është i çaktivizuar (nuk e rekomandoj, por ka :), hipervizori kalon menjëherë në teknika më të rrepta për heqjen e kujtesës. Përfundim: sigurohuni që Mjetet VMware janë në VM.
Funksionimi i Balloon Driver mund të kontrollohet nga sistemi operativ nëpërmjet VMware Tools.
Kompresimi i memories. Kjo teknikë përdoret kur ESXi arrin gjendjen e vështirë. Siç sugjeron emri, ESXi përpiqet të kompresojë një faqe 4KB RAM në 2KB, duke liruar kështu një hapësirë në kujtesën fizike të serverit. Kjo teknikë rrit ndjeshëm kohën e hyrjes në përmbajtjen e faqeve VM RAM, pasi faqja duhet së pari të dekompresohet. Ndonjëherë jo të gjitha faqet mund të kompresohen dhe vetë procesi kërkon pak kohë. Prandaj, kjo teknikë nuk është shumë efektive në praktikë.
Ndërrimi i memories. Pas një faze të shkurtër të kompresimit të memories, ESXi pothuajse në mënyrë të pashmangshme (nëse VM-të nuk janë zhvendosur te hostet e tjerë ose nuk janë fikur) kalon në Swapping. Dhe nëse ka mbetur shumë pak memorie (Gjendja e ulët), atëherë hipervizori gjithashtu ndalon ndarjen e faqeve të memories në VM, gjë që mund të shkaktojë probleme në OS mysafir të VM.
Kështu funksionon Swapping. Kur aktivizoni një makinë virtuale, krijohet një skedar me një shtesë .vswp për të. Është e barabartë në madhësi me RAM-in e parezervuar të VM-së: ky është ndryshimi midis memories së konfiguruar dhe të rezervuar. Kur Swapping po funksionon, ESXi ndërron faqet e kujtesës së makinës virtuale në këtë skedar dhe fillon të punojë me të në vend të memories fizike të serverit. Sigurisht, një memorie e tillë "RAM" është disa herë më e ngadaltë se memoria reale, edhe nëse .vswp është në ruajtje të shpejtë.
Ndryshe nga Balooning, kur faqet e papërdorura merren nga një VM, me Swapping faqet që përdoren në mënyrë aktive nga OS ose aplikacionet brenda VM mund të zhvendosen në disk. Si rezultat, performanca e VM bie deri në pikën e ngrirjes. VM është zyrtarisht duke punuar dhe të paktën mund të çaktivizohet siç duhet nga OS. Nëse jeni të durueshëm 😉
Nëse VM-të kanë shkuar në Swap, kjo është një situatë emergjente që shmanget më së miri nëse është e mundur.
Numëruesit bazë të performancës së kujtesës së makinës virtuale
Kështu që arritëm te gjëja kryesore. Për të monitoruar gjendjen e kujtesës së VM-së, ekzistojnë numëruesit e mëposhtëm:
Aktiv — tregon sasinë e RAM-it (KB) që VM ka akses në periudhën e mëparshme të matjes.
Përdorim - njësoj si Active, por si përqindje e RAM-it të konfiguruar të VM. Llogaritur duke përdorur formulën e mëposhtme: aktive ÷ madhësia e memories së konfiguruar të makinës virtuale.
Përdorimi i lartë dhe aktiv, respektivisht, nuk janë gjithmonë një tregues i problemeve të performancës së VM. Nëse VM po përdor në mënyrë agresive memorie (të paktën e akseson atë), kjo nuk do të thotë se nuk ka memorie të mjaftueshme. Përkundrazi, kjo është një arsye për të parë se çfarë po ndodh në OS.
Ekziston një alarm standard për përdorimin e kujtesës për VM-të:
Ndahet — sasia e RAM-it të VM-së e hequr duke përdorur TPS (brenda një VM ose midis VM-ve).
dhënë — sasia e memories fizike të hostit (KB) që i është ndarë VM-së. Aktivizon Shared.
konsumuar (Granted - Shared) - sasia e memories fizike (KB) që VM konsumon nga hosti. Nuk përfshin Shared.
Nëse një pjesë e kujtesës VM nuk jepet nga memoria fizike e hostit, por nga një skedar shkëmbimi, ose memoria merret nga VM përmes Drejtuesit të Balonit, kjo shumë nuk merret parasysh në "Dhuruar dhe konsumuar".
Vlerat e larta të dhëna dhe të konsumuara janë krejtësisht normale. Sistemi operativ gradualisht merr memorie nga hipervizori dhe nuk e kthen atë. Me kalimin e kohës, në një VM që funksionon në mënyrë aktive, vlerat e këtyre numëruesve i afrohen sasisë së memories së konfiguruar dhe mbeten atje.
Zero — sasia e VM RAM (KB), e cila përmban zero. Një memorie e tillë konsiderohet e lirë nga hipervizori dhe mund t'u jepet makinave të tjera virtuale. Pasi sistemi operativ i ftuar ka shkruar diçka në kujtesën e zero, ai shkon në Konsumuar dhe nuk kthehet më.
Rezervuar lart — sasia e RAM VM, (KB) e rezervuar nga hipervizori për funksionimin e VM. Kjo është një sasi e vogël, por duhet të jetë e disponueshme në host, përndryshe VM nuk do të fillojë.
Tullumbace — sasia e RAM-it (KB) e hequr nga VM duke përdorur Balloon Driver.
ngjeshur — sasia e RAM-it (KB) që është kompresuar.
swapped — sasia e RAM-it (KB), e cila, për shkak të mungesës së memories fizike në server, u zhvendos në disk.
Numëruesit e balonave dhe teknikave të tjera të rikuperimit të kujtesës janë zero.
Kështu duket grafiku me numëruesit e memories të një VM që funksionon normalisht me 150 GB RAM.
Në grafikun e mëposhtëm, VM ka probleme të dukshme. Nën grafikun mund të shihni se për këtë VM janë përdorur të gjitha teknikat e përshkruara për të punuar me RAM. Baloni për këtë VM është shumë më i madh se i konsumuar. Në fakt, VM është më shumë i vdekur sesa i gjallë.
ESXTOP
Ashtu si me CPU-në, nëse duam të vlerësojmë shpejt situatën në host, si dhe dinamikën e tij me një interval deri në 2 sekonda, duhet të përdorim ESXTOP.
Ekrani i kujtesës ESXTOP thirret me tastin "m" dhe duket kështu (fushat B,D,H,J,K,L,O të zgjedhura):
Parametrat e mëposhtëm do të jenë me interes për ne:
Mem overcommit mesatarisht — vlera mesatare e mbiabonimit të memories në host për 1, 5 dhe 15 minuta. Nëse është mbi zero, atëherë kjo është një arsye për të parë atë që po ndodh, por jo gjithmonë një tregues i problemeve.
Në rreshta PMEM/MB и VMKMEM/MB — informacion në lidhje me kujtesën fizike të serverit dhe memorien e disponueshme për VMkernel. Ndër gjërat interesante këtu mund të shihni vlerën minfree (në MB), gjendjen e hostit në memorie (në rastin tonë, e lartë).
Në rradhë NUMA/MB ju mund të shihni shpërndarjen e RAM-it nëpër nyjet NUMA (fole). Në këtë shembull, shpërndarja është e pabarabartë, e cila në parim nuk është shumë e mirë.
Më poshtë janë statistikat e përgjithshme të serverit për teknikat e rikuperimit të memories:
PSHARE/MB — këto janë statistikat e TPS;
SWAP/MB — Statistikat e përdorimit të shkëmbimit;
ZIP/MB — statistikat e kompresimit të faqes së kujtesës;
MEMCTL/MB — Statistikat e përdorimit të drejtuesit të balonave.
Për VM-të individuale, mund të na interesojë informacioni i mëposhtëm. I fsheha emrat e VM-ve për të mos ngatërruar audiencën :). Nëse metrika ESXTOP është e ngjashme me numëruesin në vSphere, unë do të jap numëruesin përkatës.
MEMSZ — sasia e memories së konfiguruar në VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + e paprekur.
DHURIM - E dhënë në MB.
TCHD — Aktiv në MBytes.
MCTL? — nëse Balloon Driver është i instaluar në VM.
MCTLSZ — Balon në MB.
MCTLGT — sasia e RAM-it (MBytes) që ESXi dëshiron të heqë nga VM përmes Driver Balloon (Memctl Target).
MCTLMAX — Sasia maksimale e RAM-it (MBytes) që ESXi mund të heqë nga një VM përmes Driver Balloon.
SWCUR — sasia aktuale e RAM-it (MBytes) e alokuar në VM nga skedari Swap.
S.W.G.T. — sasia e RAM-it (MBytes) që ESXi dëshiron t'i japë VM-së nga skedari Swap (Swap Target).
Ju gjithashtu mund të shikoni informacion më të detajuar në lidhje me topologjinë NUMA të VM përmes ESXTOP. Për ta bërë këtë, zgjidhni fushat D, G:
E VOGLA – Nyjet NUMA në të cilat ndodhet VM. Këtu mund të vëreni menjëherë vm të gjerë, të cilat nuk përshtaten në një nyje NUMA.
NRMEM – sa megabajt memorie merr VM nga nyja e largët NUMA.
NLMEM – sa megabajt memorie merr VM nga nyja lokale NUMA.
N%L – përqindja e kujtesës VM në nyjen lokale NUMA (nëse është më pak se 80%, mund të shfaqen probleme të performancës).
Kujtesa në hipervizor
Nëse numëruesit e CPU-së për një hipervizor zakonisht nuk janë me interes të veçantë, atëherë me kujtesën situata është e kundërta. Përdorimi i lartë i memories në një VM nuk tregon gjithmonë një problem të performancës, por Përdorimi i lartë i memories në një hipervizor aktivizon teknikat e menaxhimit të kujtesës dhe shkakton probleme me performancën e VM. Ju duhet të monitoroni alarmet e përdorimit të kujtesës së hostit dhe të parandaloni hyrjen e VM-ve në Swap.
Shkëmbejnë
Nëse një VM kapet në Swap, performanca e tij zvogëlohet shumë. Gjurmët e balonimit dhe kompresimit zhduken shpejt pasi RAM-i i lirë shfaqet në host, por makina virtuale nuk po nxiton të kthehet nga Swap në RAM-in e serverit.
Përpara ESXi 6.0, e vetmja mënyrë e besueshme dhe e shpejtë për të hequr një VM nga Swap ishte rindezja (më saktë, fikja/ndizja e kontejnerit). Duke filluar me ESXi 6.0, megjithëse jo plotësisht zyrtare, është shfaqur një mënyrë funksionale dhe e besueshme për të hequr një VM nga Swap. Në një nga konferencat, unë munda të bisedoja me një nga inxhinierët e VMware përgjegjës për CPU Scheduler. Ai konfirmoi se metoda është mjaft funksionale dhe e sigurt. Në përvojën tonë, as me të nuk kishte probleme.
Komandat aktuale për heqjen e një VM nga Swap Duncan Epping. Nuk do ta përsëris përshkrimin e detajuar, do të jap vetëm një shembull të përdorimit të tij. Siç mund ta shihni në pamjen e ekranit, disa kohë pas ekzekutimit të komandës së specifikuar, Swap në VM zhduket.
Këshilla për menaxhimin e RAM-it në ESXi
Më në fund, këtu janë disa këshilla që do t'ju ndihmojnë të shmangni problemet me performancën e VM për shkak të RAM-it:
- Shmangni mbiabonimin e RAM-it në grupe produktive. Këshillohet që gjithmonë të keni ~20-30% të memories së lirë në grup, në mënyrë që DRS (dhe administratori) të kenë hapësirë për të manovruar dhe VM-të të mos shkojnë në Swap gjatë migrimit. Gjithashtu, mos harroni për diferencën për tolerancën e gabimeve. Është e pakëndshme kur, kur një server dështon dhe VM-ja rindizet duke përdorur HA, disa nga makinat gjithashtu shkojnë në Swap.
- Në infrastrukturat shumë të konsoliduara, përpiquni të MOS krijoni VM me memorie më të madhe se gjysma e memories host. Kjo përsëri do të ndihmojë DRS-në të shpërndajë makinat virtuale nëpër serverët e grupeve pa asnjë problem. Ky rregull, natyrisht, nuk është universal :).
- Kujdes për alarmin e përdorimit të kujtesës së hostit.
- Mos harroni të instaloni VMware Tools në VM dhe mos e çaktivizoni Balooning.
- Merrni parasysh aktivizimin e Inter-VM TPS dhe çaktivizimin e Faqeve të Mëdha në VDI dhe mjediset e testimit.
- Nëse VM po përjeton probleme të performancës, kontrolloni nëse po përdor memorie nga një nyje NUMA e largët.
- Hiq VM-të nga Swap sa më shpejt të jetë e mundur! Ndër të tjera, nëse VM është në Swap, sistemi i ruajtjes vuan për arsye të dukshme.
Kjo është e gjitha për mua në lidhje me RAM-in. Më poshtë janë artikuj të lidhur për ata që duan të thellohen. Artikulli tjetër do t'i kushtohet storajt.
Lidhje të dobishme
Burimi: www.habr.com