Në këtë artikull do të flasim për numrat e performancës së memories RAM në vSphere.
Duket se për memorien gjithçka është më e qartë sesa për procesorin: nëse ka probleme me performancën në VM, ato janë të vështira për t'u humbur. Por nëse ato ndodhin, është shumë më e vështirë të merremi me to. Ndaj, le të fillojmë nga fillimi.
Pak teori
Memoria e përkohshme e virtual machines merret nga memoria e serverit ku punojnë VM-të. Kjo është mjaft e qartë :). Nëse memoria e serverit nuk është e mjaftueshme për të gjithë ata që duan ta përdorin, ESXi fillon të aplikojë teknika optimizimi të konsumit të memories (memory reclamation techniques). Në të kundërt, sistemet operative të VM-së do të shkonin në crash për shkak të gabimeve në qasje në RAM.
Cilat teknika do të aplikojë ESXi vendoset në varësi të ngarkesës së memories:
Gjendja e memories
Kufiri
Veprimet
I Lartë
400% nga minFree
Pasi arrihet kufiri i sipërm, faqet e mëdha të memories ndahen në të vogla (TPS punon në modalitetin standard).
Pastroni
100% nga minFree
Faqet e mëdha të memories ndahen në të vogla, TPS punon me forcë.
Butë
64% nga minFree
TPS + Balloon
Hard
32% nga minFree
TPS + Compress + Swap
I Ulët
16% nga minFree
Compress + Swap + Block
minFree është memoria e nevojshme për funksionimin e hipervizorit.
Derisa ESXi 4.1 përfshihej, minFree nga default ishte fiksuar në 6% të volumit të memories së serverit (procenti mund të ndryshohej përmes opsionit Mem.MinFreePct në ESXi). Në versionet më të fundit, për shkak të rritjes së volumit të memories në serverë, minFree filloi të llogaritej në bazë të volumit të memories së hostit, në vend të një vlerë të fiksuar procentuale.
Vlera e minFree (nga default) llogaritet si më poshtë:
Procenti i memories e rezervuar për minFree
Shtrirja e memories
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Memoria e mbetur
Për shembull, për një server me 128 GB RAM, vlera MinFree do të ishte si vijon:
MinFree = 245.76 + 327.68 + 327.68 + 1024 = 1925.12 MB = 1.88 GB
Vlera reale mund të ndryshojë për disa qindra MB, kjo varet nga serveri dhe memoria e përkohshme.
Procenti i memories e rezervuar për minFree
Shtrirja 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%
Memoria e mbetur (100 GB)
1024 MB
Për zakonisht, për mjediset prodhuese, gjendja normale është vetëm ajo e Lartë. Për ambientet e testimit dhe zhvillimit, gjendjet e Qarta/Butë janë të pranueshme. Nëse memoria e operativës në host ka mbetur më pak se 64% MinFree, atëherë pajisjet Virtuale (VM) që funksionojnë mbi të, patjetër do të kenë probleme me performancën.
Në çdo gjendje aplikohen teknika të caktuara të rikuperimit të memories duke filluar nga TPS, e cila ka ndikim të vogël në performancën e VM, deri te Swapping. Do t'ju tregoj më shumë për to.
Transparent Page Sharing (TPS). TPS është, thjesht, deduplication e faqeve të memories së operativës së makinave virtuale në server.
ESXi kërkon faqe të njëjta të memories së operativës së makinave virtuale, duke llogaritur dhe krahasuar hash-in e faqeve, dhe heq kopjet e faqeve, duke i zëvendësuar ato me reference në të njëjtën faqe në memorien fizike të serverit. Si rezultat, konsumimi i memories fizike reduktohet dhe është e mundur të arrihet një përshkallëzim i caktuar i memories praktikisht pa ulje të performancës.
Ky mekanizëm funksionon vetëm për faqe memories me madhësi 4 KByte (faqe të vogla). Hypervizori nuk përpiqet madje për të deduplicuar faqet me madhësi 2 MByte (faqe të mëdha): shansi për të gjetur faqe të njëjta të tillë nuk është i lartë.
Në mënyrë të paracaktuar, ESXi cakton memorien për faqet e mëdha. Shkëputja e faqeve të mëdha në të vogla fillon kur arrihet pragu i gjendjes Lartë dhe ndodh forcërisht kur arrihet gjendja Qartë (shih tabelën e gjendjeve të hypervizorit).
NĂ«se dĂ«shironi qĂ« TPS tĂ« fillojĂ« punĂ«n, pa pritur mbushjen e memories sĂ« operativĂ«s sĂ« hostit, nĂ« mundĂ«sitĂ« e avancuara tĂ« ESXi duhet tĂ« vendosni vlerĂ«n âMem.AllocGuestLargePageâ nĂ« 0 (e cila Ă«shtĂ« parazgjedhja 1). AtĂ«herĂ«, caktimi i faqeve tĂ« mĂ«dha tĂ« memories pĂ«r makinat virtuale do tĂ« jetĂ« i çaktivizuar.
Që nga dhjetori 2014, në të gjitha lëshimet e ESXi, TPS midis VM-ve është parazgjedhur e çaktivizuar, pasi u gjet një dobësi, e cila teorikisht mund të lejojë për të aksesuar nga një VM memorien e operativës së një VM tjetër. Detajet këtu. Nuk kam hasur informacion për realizimin praktik të shfrytëzimit të dobësisë TPS.
Politika TPS kontrollohet pĂ«rmes opsionit tĂ« avancuar âMem.ShareForceSaltingâ nĂ« ESXi:
0 â Inter-VM TPS. TPS funksionon pĂ«r faqe tĂ« ndryshme VM;
1 â TPS pĂ«r VM me vlerĂ«n e njĂ«jtĂ« âsched.mem.pshare.saltâ nĂ« VMX;
2 (parazgjedhja) â Intra-VM TPS. TPS funksionon pĂ«r faqe brenda VM.
Padyshmja e joÌneve ka qeneÌ e nevojshme per teÌ fikur faqet e medha dhe teÌ aktivizohet Inter-VM TPS neÌ gethet e testimit. Kjo mund teÌ perdoret gjithashtu per gethet me numra teÌ madh te VM-ve te njejte. Per shembull, ne gethet me VDI, kursimi i memories fizike mund teÌ arrije disa dhjete perqind.
Memoria Ballooning. Ballooning nuk eshte me nje teknike e padukur dhe transparente per sistemin operativ te VM-ve si TPS. Por me aplikuar teÌ menqur, mund teÌ banohet dhe madje teÌ punohet me Ballooning.
Se bashku me VMware Tools, ne VM instalohen nje drejtuese e veçante, e njohur si Balloon Driver (po ashtu dhe vmmemctl). Kur hypervisor-i fillon teÌ kete problemin e mungeses se memories fizike dhe kalon ne gjendjen Soft, ESXi i kerkon VM-se te ktheje memorien operativ te paneÌpĂ«rdorur permes ketij Balloon Driver. Drejtuesi, nĂ« anĂ«n tjetĂ«r, funksionon ne nivelin e sistemit operativ dhe kerkon memorien e lirĂ« nga ai. Hypervisor-i sheh se cilat faqe te memories fizike ka zene Balloon Driver, merr memorien nga makina virtuale dhe ia kthen hostit. Probleme me funksionimin e sistemit operativ nuk ndodhin, pasi ne nivelin e sistemit operativ memoria Ă«shtĂ« e zene nga Balloon Driver. NĂ« mĂ«nyrĂ« tĂ« paracaktuar, Balloon Driver mund tĂ« marrĂ« deri nĂ« 65% tĂ« memories sĂ« VM-sĂ«.
Nëse VMware Tools nuk janë instaluar në VM ose Ballooning është çaktivizuar (nuk e rekomandoj, por ka :), hypervisor-i kalon menjëherë në teknika më të rrepta për të marrë memorien. Përfundimi: siguroni që VMware Tools të jenë në VM.
Funksionimin e Balloon Driver-it mund ta kontrolloni nga OS përmes VMware Tools..
Kompresimi i Memories. Kjo teknikë aplikohet kur ESXi arrin në gjendjen Hard. Siç dallohet nga emri, ESXi përpiqet të comprimojë një faqe 4 KB të memories operativ në 2 KB dhe në këtë mënyrë të lirojë pak hapësirë në memorien fizike të serverit. Kjo teknikë ndjeshëm rrit kohën e qasjes në përmbajtjen e faqeve të memories operativ të VM-së, pasi faqeja duhet të dekompresohet paraprakisht. Ndonjëherë nuk arrin të comprimojë të gjitha faqe dhe vetë procesi merr disa kohë. Kështu që kjo teknikë nuk është shumë efektive në praktikë.
Ndryshimi i Memories. Pas një faze të shpejtë të Kompresimit të Memories, ESXi pothuajse pa përjashtim (nëse VM-të nuk janë zhvendosur në host të tjerë ose nuk janë fikur) kalon në Ndryshim. Dhe nëse mbetet shumë pak memorje (gjendja e Ulët), atëherë hypervisor-i gjithashtu ndalon akordimin e faqeve të memories për VM, e cila mund të shkaktojë probleme në sistemet operative mikpritëse të VM-së.
KĂ«tu Ă«shtĂ« si funksionon Swapping. Kur aktivizohet makina virtuale, krijohet njĂ« skedar me zgjerimin .vswp. SipĂ«rfaqja e tij Ă«shtĂ« e barabartĂ« me memorien e papĂ«rdorur RAM tĂ« VM-sĂ«: kjo Ă«shtĂ« diferenca midis memorjes sĂ« konfiguruar dhe asaj tĂ« rezervuar. Kur funksionon Swapping, ESXi shkarkon faqet e memorjes sĂ« makinĂ«s virtuale nĂ« kĂ«tĂ« skedar dhe fillon tĂ« punojĂ« me tĂ« nĂ« vend tĂ« memorjes fizike tĂ« serverit. Natyrisht, njĂ« memorie e tillĂ« âaktiveâ Ă«shtĂ« disa herĂ« mĂ« e ngadalshme se e vĂ«rteta, edhe nĂ«se .vswp ndodhet nĂ« njĂ« magazinĂ« tĂ« shpejtĂ«.
NĂ« dallim nga Ballooning, kur VM-sĂ« i ndĂ«rpriten faqet e panjohura, gjatĂ« Swapping-ut mund tĂ« kalojnĂ« nĂ« disk faqet qĂ« pĂ«rdoren aktivisht nga OS ose aplikacionet brenda VM-sĂ«. Si rezultat, performanca e VM-sĂ« bie deri nĂ« ngecje. VM-ja operon formalisht dhe mund tĂ« çâaktivizohet siç duhet nga OS. NĂ«se jeni tĂ« durueshĂ«m đ
NĂ«se VM-tĂ« kalojnĂ« nĂ« Swap â kjo Ă«shtĂ« njĂ« situatĂ« e papastĂ«r qĂ« duhet tĂ« shmanget sa mĂ« shumĂ« tĂ« jetĂ« e mundur.
Numrat kryesorë të performancës së memorjes së makinës virtuale
Këtu erdhëm në tërësinë. Për monitorimin e gjendjes së memorjes në VM ka këta numra:
Aktiv â tregon vĂ«llimin e memorjes RAM (Kbyte), tĂ« cilĂ«s VM-ja i kishte qasje nĂ« periudhĂ«n e mĂ«parshme tĂ« matjes.
PĂ«rdorimi â e njĂ«jta si Aktiv, por nĂ« pĂ«rqindje tĂ« memorjes sĂ« konfiguruar tĂ« VM-sĂ«. Llogaritet me formulĂ«n e mĂ«poshtme: aktiv Ă· madhĂ«sia e memorie tĂ« konfiguruar tĂ« makinĂ«s virtuale.
Një Usage dhe Aktiv të larta, përkatësisht, nuk janë gjithmonë tregues të problemeve të performancës së VM-së. Nëse VM-ja përdor agresivisht memorjen (të paktën ka qasje në të), kjo nuk do të thotë se ka mungesë memorjeje. Më tepër, kjo është një mundësi për të parë se çfarë ndodh në OS.
Ka një Alarm standard për Përdorimin e Memorjes për VM:
Shared â vĂ«llimi i memorjes RAM tĂ« VM-sĂ«, e cila Ă«shtĂ« e deduplicuar me ndihmĂ«n e TPS (brenda VM-sĂ« ose ndĂ«rmjet VM-ve).
E dhĂ«nĂ« â vĂ«llimi i memorjes fizike tĂ« hostit (Kbyte), e cila iu dha VM-sĂ«. PĂ«rfshin tĂ« ndarĂ«.
E konsumuar (E dhĂ«nĂ« â E ndarĂ«) â vĂ«llimi i memorjes fizike (Kbyte), qĂ« VM-ja e konsumon nga hosti. Nuk pĂ«rfshin tĂ« ndarĂ«.
Nëse një pjesë e memorjes së VM-së jepet jo nga memoria fizike e hostit, por nga skedari swap ose memorja merret nga VM-ja përmes Balloon Driver, ky vëllim nuk merret parasysh në E dhënë dhe të konsumuar.
Vlerat e larta të Granted dhe Consumed janë krejtësisht normale. Sistemi operativ gradualisht merr kujtesën nga hiper-vizori dhe nuk e kthen atë përsëri. Me kalimin e kohës, për VM-në e cila punon aktivisht, vlerat e këtyre numrit afroheshin me volumet e memorjes së konfiguruar, dhe aty mbeten.
Zero â volumi i memorjes RAM tĂ« VM-sĂ« (KB), e cila pĂ«rmban zero. Kjo memorie konsiderohet nga hiper-vizori si e lirĂ« dhe mund tĂ« jepet pĂ«r VM tĂ« tjera. Pasi sistemi operativ mik i ka shkruar diçka nĂ« memorjen e zĂ«vendĂ«suar, kalon nĂ« Consumed dhe nuk kthehet mĂ«.
Reserved Overhead â volumi i memorjes RAM tĂ« VM-sĂ« (KB) i rezervuar nga hiper-vizori pĂ«r operimin e VM-sĂ«. Ky Ă«shtĂ« njĂ« volum i vogĂ«l, por duhet patjetĂ«r tĂ« jetĂ« nĂ« dispozicion nĂ« host, nd otherwise VM nuk do tĂ« nis.
Balloon â volumi i memorjes RAM (KB) e cila Ă«shtĂ« marrĂ« nga VM pĂ«rmes Balloon Driver.
Compressed â volumi i memorjes RAM (KB) qĂ« arriti tĂ« kompresohej.
Swapped â volumi i memorjes RAM (KB) e cila pĂ«r shkak tĂ« mungesĂ«s sĂ« kujtesĂ«s fizike nĂ« server Ă«shtĂ« transferuar nĂ« disk.
Balloon dhe numrat e tjerë të teknikave të rikuperimit të memories janë të barabartë me zero.
Këtu është si duket grafiku me numrat e memories për një VM të punës normale me 150 GB RAM.
Në grafikun më poshtë, VM ka probleme të dukshme. Nën grafik shikohet se për këtë VM janë përdorur të gjitha teknikës e përshkruara në lidhje me kujtesën. Balloon për këtë VM është shumë më i madh se Consumed. Në fakt, VM është më shumë e vdekur sesa e gjallë.
ESXTOP
Si me CPU-në, nëse duam të vlerësojmë situatën në host menjëherë dhe gjithashtu dinamikën e saj me intervale deri në 2 sekonda, është mirë të përdorim ESXTOP.
Ekrani ESXTOP për Memory thirret me çelësin 'm' dhe duket si më poshtë (këtu janë zgjedhur fushat B,D,H,J,K,L,O):
Parametrat më të rëndësishëm për ne do të jenë si më poshtë:
Mem overcommit avg â vlera mesatare e mbishkruar e memories nĂ« host pĂ«r 1, 5 dhe 15 minuta. NĂ«se Ă«shtĂ« mĂ« e lartĂ« se zero, kjo Ă«shtĂ« njĂ« arsye pĂ«r tĂ« parĂ« se çfarĂ« po ndodh, por nuk Ă«shtĂ« gjithmonĂ« tregues i problemeve.
NĂ« rreshtat PMEM/MB dhe VMKMEM/MB â informacion rreth memories fizike tĂ« serverit dhe memories tĂ« disponueshme pĂ«r VMkernel. Nga e rĂ«ndĂ«sishmja kĂ«tu mund tĂ« shikohet vlera minfree (nĂ« MB), gjendja e hostit pĂ«r kujtesĂ«n (nĂ« rastin tonĂ«, e lartĂ«).
Në rreshtin NUMA/MB mund të shikohet shpërndarja e memories RAM sipas NUMA-nodave (socketëve). Në këtë shembull, shpërndarja është e pabarabartë, që në thelb nuk është shumë mirë.
Më poshtë janë statistikat e përgjithshme për serverin mbi teknikat e rikuperimit të memories:
PSHARE/MB â kjo Ă«shtĂ« statistika e TPS;
SWAP/MB â statistika e pĂ«rdorimit tĂ« Swap;
ZIP/MB â statistika e kompresionit tĂ« faqeve tĂ« memories;
MEMCTL/MB â statistika e pĂ«rdorimit tĂ« Balloon Driver.
Për çdo VM të veçantë, mund të na interesojë informacioni në vijim. Emrat e VM-së i kam fshhur, për të mos e shqetësuar audiencën :). Nëse metrika ESXTOP është e ngjashme me numëruesin në vSphere, po sjell numëruesin përkatës.
MEMSZ â sasia e memories, e konfiguruar nĂ« VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT â Granted nĂ« megabajt.
TCHD â Active nĂ« megabajt.
MCTL? â a Ă«shtĂ« e instaluar Balloon Driver nĂ« VM.
MCTLSZ â Balloon nĂ« megabajt.
MCTLGT â sasia e memories RAM (megabajt), e cila ESXi do tĂ« dĂ«shirojĂ« ta tĂ«rheqĂ« nga VM pĂ«rmes Balloon Driver (Memctl Target).
MCTLMAX â sasia maksimale e memories RAM (megabajt), e cila ESXi mund ta tĂ«rheqĂ« nga VM pĂ«rmes Balloon Driver.
SWCUR â sasia aktuale e memories RAM (megabajt), e dhĂ«nĂ« VM nga skedari Swap.
SWGT â sasia e memories RAM (megabajt), e cila ESXi dĂ«shiron tĂ« japĂ« VM nga skedari Swap (Swap Target).
Gjithashtu përmes ESXTOP mund të shihni më shumë informacion mbi topologjinë NUMA të VM. Për këtë është e nevojshme të zgjidhen fushat D,G:
NHN â nyjat NUMA, nĂ« tĂ« cilat ndodhet VM. KĂ«tu mund ta vini re VM tĂ« gjĂ«rĂ« qĂ« nuk i pĂ«rputhen njĂ« nyje NUMA.
NRMEM â sa megabajt memories VM merr nga njĂ« nyjĂ« NUMA tĂ« distancuar.
NLMEM â sa megabajt memories VM merr nga njĂ« nyjĂ« NUMA lokale.
N%L â pĂ«rqindja e memories VM nĂ« nyjĂ«n NUMA lokale (nĂ«se Ă«shtĂ« mĂ« pak se 80% â mund tĂ« ketĂ« probleme me performancĂ«n).
Memoria në hypervisor
Nëse numëruesit e CPU-së në hypervisor zakonisht nuk paraqesin interes të veçantë, situata me memory është e kundërt. Përdorimi i Lartë i Memories në VM nuk tregon gjithmonë për një problem me performancën, por një Përdorim i Lartë i Memories në hypervisor, në fakt aktivizon teknikat e menaxhimit të memories dhe shkakton probleme me performancën e VM. Duhet të monitoroni alarmin e Përdorimit të Memories në Host dhe të mos lejoni që VM të kalojë në Swap.
Unswap
Nëse VM kalon në Swap, performanca e saj zvogëlohet ndjeshëm. Shkallët e Ballooning dhe kompresionit shuhen shpejt pas shfaqjes së memories RAM të lirë në host, por VM nuk nxiton aspak të kthehet nga Swap në memories RAM të serverit.
Deri në versionin ESXi 6.0, mënyra e vetme e besueshme dhe e shpejtë për të nxjerrë VM nga Swap ishte rinisja (nëse jemi më të saktë, fikja/nisja e kontejnerit). Që nga ESXi 6.0 ka dalë një mënyrë, edhe pse jo plotësisht zyrtare, por e punueshme dhe e besueshme për të nxjerrë VM nga Swap. Në një nga konferencat, pata mundësinë të bisedoj me një nga inxhinierët e VMware që ishte përgjegjës për CPU Scheduler. Ai konfirmoi se mënyra është me të vërtetë funksionale dhe e sigurt. Në përvojën tonë, nuk kemi vënë re probleme me të.
Komandat për të nxjerrë VM nga Swap Duncan Epping. Nuk do të përsëris përshkrimin e detajuar, thjesht do t'ju jap një shembull të përdorimit të saj. Siç shihet në screenshot, pas një periudhe pas ekzekutimit të komandës të cituar, Swap në VM zhduket.
Këshilla për menaxhimin e memories në ESXi
Në fund, do të jap disa këshilla që do t'ju ndihmojnë të shmangni probleme me performancën e VM për shkak të memories:
- Mos lejoni mbipopullimin e memories në klasterët produktivë. Preferohet që gjithmonë të ketë rreth 20-30% memory të lirë në klaster, në mënyrë që DRS (dhe administratori) të ketë hapësirë për manovrim, dhe kur migroni VM, ato të mos kalojnë në Swap. Gjithashtu mos harhoni rezervat për qëndrueshmëri. Nuk është e këndshme kur, në rastin e dështimit të një serveri dhe rinisjes së VM me HA, disa makineri të shkojnë në Swap.
- Në infrastrukturat me konsolidim të lartë, përpiquni të MOS krijoni VM me më shumë se gjysma e memories së hostit. Kjo, gjithashtu, do t'i ndihmojë DRS-së të shpërndajë pa probleme makinat virtuale në serverët e klasterit. Ky rregull, sigurisht, nuk është universal :).
- K kontrolloni Alarmin e Përdorimit të Memories së Hostit.
- Mos harroni të instaloni VMware Tools në VM dhe mos e çaktivizoni Ballooning.
- Mundohuni të aktivizoni Inter-VM TPS dhe të ndaloni Large Pages në mjedise me VDI dhe në mjedise testuese.
- Nëse VM po përjeton probleme me performancën, kontrolloni nëse është duke përdorur memories nga një NUMA-nodë të largët.
- Nxirrni VM nga Swap sa më shpejt të jetë e mundur! Përveç gjithçkaje, nëse VM është në Swap, për shkak të arsyesh të dukshme, përballet me probleme në ruajtjen.
Këtu përfundon diskutimi për memorizimin. Më poshtë janë disa artikuj në lidhje me temën për ata që dëshirojnë të thellohen në detaje. Artikulli i ardhshëm do të jetë për ruajtjen.
Useful links
Burimi: habr.com
