In hierdie artikel sal ons praat oor die prestasietellers van ewekansige toegang geheue (RAM) in vSphere.
Dit blyk dat alles met geheue duideliker is as met die verwerker: as 'n VM prestasieprobleme het, is dit moeilik om dit nie raak te sien nie. Maar as hulle verskyn, is dit baie moeiliker om hulle te hanteer. Maar eerste dinge eerste.
'N bietjie teorie
Die RAM van virtuele masjiene word geneem uit die geheue van die bediener waarop die VM's loop. Dit is redelik duidelik :). As die bediener se RAM nie genoeg is vir almal nie, begin ESXi geheueherwinningstegnieke gebruik om die verbruik van RAM te optimaliseer. Andersins sal VM-bedryfstelsels ineenstort met RAM-toegangsfoute.
Watter tegnieke om ESXi te gebruik, besluit afhangende van die las van RAM:
Geheue status
grens
Aktiwiteit
Hoogte
400% van minGratis
Nadat die boonste limiet bereik is, word groot geheuebladsye in kleins verdeel (TPS werk in standaardmodus).
duidelik
100% van minGratis
Groot geheuebladsye word in kleintjies opgebreek, TPS word gedwing om te werk.
Soft
64% van minGratis
TPS + Ballon
Hard
32% van minGratis
TPS + Compress + Ruil
Laagte
16% van minGratis
Druk saam + Ruil + Blok
minFree is die RAM wat nodig is vir die hypervisor om te werk.
Voor ESXi 4.1 ingesluit, is minFree by verstek reggestel - 6% van die bediener se RAM (die persentasie kan verander word via die Mem.MinFreePct-opsie op ESXi). In latere weergawes, as gevolg van die toename in geheuegroottes op bedieners, het minFree begin bereken word op grond van die hoeveelheid gasheergeheue, en nie as 'n vaste persentasie nie.
Die minFree (verstek) waarde word soos volg bereken:
Persentasie geheue gereserveer vir minFree
Geheue reeks
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Oorblywende geheue
Byvoorbeeld, vir 'n bediener met 128 GB RAM, sal die MinFree-waarde wees:
MinGratis = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Die werklike waarde kan met 'n paar honderd MB verskil, dit hang af van die bediener en RAM.
Persentasie geheue gereserveer vir minFree
Geheue reeks
Waarde vir 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Oorblywende geheue (100 GB)
1024 MB
Gewoonlik, vir produktiewe erwe, kan slegs die Hoë toestand as normaal beskou word. Vir toets- en ontwikkelingsbanke kan duidelike/sagte toestande aanvaarbaar wees. As die RAM op die gasheer minder as 64% MinFree is, dan het die VM's wat daarop loop beslis prestasieprobleme.
In elke toestand word sekere geheueherwinningstegnieke toegepas, wat begin met TPS, wat feitlik nie die werkverrigting van die VM beïnvloed nie, en eindig met Swapping. Ek sal jou meer van hulle vertel.
Deursigtige bladsydeling (TPS). TPS is, rofweg gesproke, deduplisering van virtuele masjiengeheuebladsye op 'n bediener.
ESXi soek identiese bladsye van virtuele masjien-RAM deur die hash-som van die bladsye te tel en te vergelyk, en verwyder duplikaatbladsye en vervang dit met skakels na dieselfde bladsy in die bediener se fisiese geheue. As gevolg hiervan word fisieke geheueverbruik verminder en 'n mate van geheue-oorintekening kan bereik word met min of geen prestasie-agteruitgang.
Hierdie meganisme werk net vir 4 KB geheue bladsye (klein bladsye). Die hypervisor probeer nie eers bladsye van 2 MB (groot bladsye) dedupeer nie: die kans om identiese bladsye van hierdie grootte te vind is nie groot nie.
By verstek ken ESXi geheue toe aan groot bladsye. Die opbreek van groot bladsye in klein bladsye begin wanneer die Hoë toestand drempel bereik word en word geforseer wanneer die Clear toestand bereik word (sien die hipervisor toestand tabel).
As jy wil hê dat TPS moet begin werk sonder om te wag dat die gasheer-RAM vol is, moet jy in Advanced Options ESXi die waarde stel "Mem.AllocGuestLargePage" na 0 (verstek 1). Dan sal die toekenning van groot geheue bladsye vir virtuele masjiene gedeaktiveer word.
Sedert Desember 2014, in alle vrystellings van ESXi, is TPS tussen VM's by verstek gedeaktiveer, aangesien 'n kwesbaarheid gevind is wat teoreties toegang van een VM tot die RAM van 'n ander VM toelaat. Besonderhede hier. Ek het nie inligting oor die praktiese implementering van die ontginning van die TPS-kwesbaarheid teëgekom nie.
TPS-beleid word beheer via gevorderde opsie "Mem.ShareForceSalting" op ESXi:
0 - Inter-VM TPS. TPS werk vir bladsye van verskillende VM's;
1 – TPS vir VM met dieselfde “sched.mem.pshare.salt” waarde in VMX;
2 (verstek) - Intra-VM TPS. TPS werk vir bladsye binne die VM.
Dit maak beslis sin om groot bladsye af te skakel en Inter-VM TPS op toetsbanke aan te skakel. Dit kan ook gebruik word vir staanplekke met 'n groot aantal van dieselfde tipe VM. Byvoorbeeld, op staanders met VDI kan besparings in fisiese geheue tientalle persent bereik.
geheue ballonvaart. Ballonvaart is nie meer so 'n onskadelike en deursigtige tegniek vir die VM-bedryfstelsel soos TPS nie. Maar met behoorlike toepassing kan jy met Balloonvaart leef en selfs werk.
Saam met Vmware Tools word 'n spesiale drywer genaamd Balloon Driver (ook bekend as vmmemctl) op die VM geïnstalleer. Wanneer die hiperviser begin om uit fisiese geheue te raak en die Sagte toestand betree, vra ESXi die VM om ongebruikte RAM deur hierdie Balloon Driver terug te eis. Die bestuurder werk op sy beurt op die bedryfstelselvlak en vra vrye geheue daarvan. Die hiperviseerder sien watter bladsye van fisiese geheue die ballonbestuurder beset het, neem die geheue van die virtuele masjien af en stuur dit terug na die gasheer. Daar is geen probleme met die werking van die bedryfstelsel nie, aangesien die geheue op die bedryfstelselvlak deur die ballonbestuurder beset word. By verstek kan Balloon Driver tot 65% van VM geheue neem.
As VMware Tools nie op die VM geïnstalleer is nie of Ballooning is gedeaktiveer (ek beveel nie aan nie, maar daar is :), skakel die hiperviseerder dadelik oor na strenger geheueverwyderingstegnieke. Gevolgtrekking: maak seker dat VMware Tools op die VM is.
Balloonbestuurder se werking kan vanaf die bedryfstelsel nagegaan word via VMware Tools.
geheue kompressie. Hierdie tegniek word gebruik wanneer ESXi die harde toestand bereik. Soos die naam aandui, probeer ESXi om 'n 4KB-bladsy RAM in 2KB te krimp en sodoende 'n bietjie spasie op die bediener se fisiese geheue vry te maak. Hierdie tegniek verhoog die toegangstyd tot die inhoud van die VM RAM-bladsye aansienlik, aangesien die bladsy eers ontkomprimeer moet word. Soms kan nie alle bladsye saamgepers word nie en neem die proses self 'n geruime tyd. Daarom is hierdie tegniek nie baie effektief in die praktyk nie.
geheue ruil. Na 'n kort geheue-kompressiefase sal ESXi byna onvermydelik (as die VM's nie na ander gashere vertrek het of afgeskakel is nie) oorskakel na Swapping. En as daar baie min geheue oor is (Lae toestand), dan hou die hiperviser ook op om geheuebladsye aan die VM toe te ken, wat probleme in die gasbedryfstelsel van die VM kan veroorsaak.
Hier is hoe omruil werk. Wanneer jy 'n virtuele masjien aanskakel, word 'n lêer met die .vswp-uitbreiding daarvoor geskep. Dit is gelyk in grootte aan die VM se ongereserveerde RAM: dit is die verskil tussen gekonfigureerde en gereserveerde geheue. Wanneer Swapping loop, laai ESXi virtuele masjiengeheuebladsye in hierdie lêer af en begin daarmee werk in plaas van die bediener se fisiese geheue. Natuurlik is sulke “operatiewe” geheue verskeie ordes van grootte stadiger as die regte een, selfs al lê .vswp op vinnige berging.
Anders as Ballooning, wanneer ongebruikte bladsye van die VM geneem word, met Swapping, kan bladsye wat aktief deur die OS of toepassings binne die VM gebruik word, na skyf skuif. As gevolg hiervan daal die werkverrigting van die VM tot die punt van vriespunt. Die VM werk formeel en ten minste kan dit behoorlik gedeaktiveer word vanaf die bedryfstelsel. As jy geduldig is 😉
As die VM'e na Swap gegaan het, is dit 'n abnormale situasie, wat die beste vermy word indien moontlik.
Sleutel VM geheue werkverrigting tellers
So het ons by die hoofpunt gekom. Om die toestand van geheue in die VM te monitor, is daar die volgende tellers:
Aktief — toon die hoeveelheid RAM (KB) waartoe die VM toegang gekry het in die vorige metingsperiode.
Gebruik - dieselfde as aktief, maar as 'n persentasie van die gekonfigureerde RAM van die VM. Bereken deur die volgende formule te gebruik: aktief ÷ virtuele masjien gekonfigureerde geheue grootte.
Hoë gebruik en aktief, onderskeidelik, is nie altyd 'n aanduiding van VM-werkverrigtingprobleme nie. As die VM geheue aggressief gebruik (ten minste toegang daartoe kry), beteken dit nie dat daar nie genoeg geheue is nie. Dit is eerder 'n geleentheid om te sien wat in die bedryfstelsel gebeur.
Daar is 'n standaard geheuegebruikalarm vir VM's:
Gedeelde - die hoeveelheid VM RAM gededupliseer met TPS (binne die VM of tussen VM'e).
toegestaan - die hoeveelheid fisiese gasheergeheue (KB) wat aan die VM gegee is. Sluit Gedeelde in.
verteer (Toegegee - Gedeel) - die hoeveelheid fisiese geheue (KB) wat die VM van die gasheer verbruik. Sluit nie Gedeel in nie.
As 'n deel van die VM-geheue gegee word nie uit die fisiese geheue van die gasheer nie, maar van die ruillêer, of die geheue word van die VM deur die Ballonbestuurder geneem, word hierdie bedrag nie in Toegeken en Verbruik in ag geneem nie.
Hoë toegekende en verbruikte waardes is heeltemal normaal. Die bedryfstelsel neem geleidelik geheue van die hipervisor en gee dit nie terug nie. Met verloop van tyd, in 'n aktief lopende VM, benader die waardes van hierdie tellers die hoeveelheid gekonfigureerde geheue en bly daar.
Zero — die hoeveelheid VM RAM (KB), wat nulle bevat. Sulke geheue word deur die hipervisor as vry beskou en kan aan ander virtuele masjiene gegee word. Nadat die gas-bedryfstelsel iets in 'n nulgeheue geskryf het, gaan dit na Verbruik en keer nie terug nie.
Voorbehou oorhoofse — die hoeveelheid VM RAM, (KB) wat deur die hipervisor gereserveer is vir VM-werking. Dit is 'n klein hoeveelheid, maar dit moet op die gasheer beskikbaar wees, anders sal die VM nie begin nie.
Ballon — die hoeveelheid RAM (KB) waarop beslag gelê is op die VM met behulp van die ballonbestuurder.
saamgeperste - die hoeveelheid RAM (KB) wat saamgepers is.
verruil - die hoeveelheid RAM (KB) wat, weens 'n gebrek aan fisiese geheue op die bediener, na skyf geskuif het.
Ballon en ander geheue herwinning tegnieke tellers is nul.
Dit is hoe die grafiek met Memory tellers lyk vir 'n normaal werkende VM met 150 GB RAM.
In die grafiek hieronder het die VM ooglopende probleme. Onder die grafiek kan jy sien dat vir hierdie VM al die beskryfde tegnieke vir werk met RAM gebruik is. Ballon vir hierdie VM is baie groter as Verbruik. Trouens, die VM is meer dood as lewend.
ESXTOP
Soos met die SVE, as ons vinnig die situasie op die gasheer wil assesseer, sowel as die dinamika daarvan met 'n interval van tot 2 sekondes, moet ons ESXTOP gebruik.
Die ESXTOP-skerm deur Memory word met die "m"-sleutel opgeroep en lyk so (velde B, D, H, J, K, L, O is gekies):
Die volgende parameters sal vir ons van belang wees:
Mem oorpleeg gem - die gemiddelde waarde van geheue-oortekening op die gasheer vir 1, 5 en 15 minute. As dit bo nul is, dan is dit 'n geleentheid om te sien wat gebeur, maar nie altyd 'n aanduiding van probleme nie.
In lyne PMEM/MB и VMKMEM/MB - inligting oor die fisiese geheue van die bediener en die geheue beskikbaar vir VMkernel. Van die interessante hier kan jy die waarde van minfree (in MB), die toestand van die gasheer in die geheue (in ons geval, hoog) sien.
In lyn NUMA/MB jy kan die verspreiding van RAM deur NUMA nodusse (sokke) sien. In hierdie voorbeeld is die verspreiding ongelyk, wat in beginsel nie baie goed is nie.
Die volgende is algemene bedienerstatistieke oor geheueherwinningstegnieke:
PSHARE/MB is TPS-statistieke;
RUIL/MB — Ruil gebruikstatistieke uit;
zip/MB - geheue bladsy kompressie statistieke;
MEMCTL/MB - Ballonbestuurder-gebruikstatistieke.
Vir individuele VM's sal ons dalk in die volgende inligting belangstel. Ek het die VM-name weggesteek om nie die gehoor te verwar nie :). As die ESXTOP-metriek soortgelyk is aan die teller in vSphere, gee ek die ooreenstemmende teller.
MEMSZ — die hoeveelheid geheue wat op die VM (MB) gekonfigureer is.
MEMSZ = GRANT + MCTLSZ + SWCUR + onaangeraak.
GRANT — Toegestaan aan MB.
TCHD - Aktief in MB.
MCTL? - of Balloon Driver op die VM geïnstalleer is.
MCTLSZ — Ballon na MB.
MCTLGT — die hoeveelheid RAM (MB) wat ESXi van die VM wil neem via Balloon Driver (Memctl Target).
MCTLMAX - die maksimum hoeveelheid RAM (MB) wat ESXi van die VM deur die ballonbestuurder kan neem.
SWCUR — die huidige hoeveelheid RAM (MB) wat vanaf die Swap-lêer aan die VM toegewys is.
S.W.G.T. - die hoeveelheid RAM (MB) wat ESXi vanaf die Swap-lêer (Swap Target) aan die VM wil gee.
Ook, deur ESXTOP, kan jy meer gedetailleerde inligting oor die NUMA topologie van die VM sien. Om dit te doen, kies die velde D, G:
KLEIN – NUMA nodusse waarop die VM geleë is. Hier kan jy dadelik wye vm opmerk, wat nie op een NUMA-knoop pas nie.
NRMEM - hoeveel megagrepe geheue die VM neem van die afgeleë NUMA-knooppunt.
NLMEM - hoeveel megagrepe geheue die VM van die plaaslike NUMA-nodus neem.
N%L – persentasie VM-geheue op die plaaslike NUMA-knooppunt (indien minder as 80%, kan prestasieprobleme voorkom).
Geheue op die hipervisor
As die SVE-tellers vir die hipervisor gewoonlik nie van besondere belang is nie, word die situasie met geheue omgekeer. Hoë geheuegebruik op 'n VM dui nie altyd op 'n prestasieprobleem nie, maar hoë geheuegebruik op 'n hiperviser veroorsaak geheuebestuurtegnieke en veroorsaak prestasieprobleme in die VM. Gasheergeheuegebruik-alarms moet gemonitor word om te verhoed dat die VM in Swap kom.
uitruil
As 'n VM in Swap is, word sy werkverrigting aansienlik verminder. Spore van ballonvaart en kompressie verdwyn vinnig nadat gratis RAM op die gasheer verskyn het, maar die virtuele masjien is nie haastig om van Swap na die bediener-RAM terug te keer nie.
Voor ESXi 6.0 was die enigste betroubare en vinnige manier om 'n VM uit Swap te kry om te herlaai (om meer presies te wees, skakel die houer af/aan). Begin met ESXi 6.0, hoewel nie heeltemal amptelik nie, het 'n werkende en betroubare manier verskyn om 'n VM van Swap te verwyder. By een van die konferensies kon ek met een van die VMware-ingenieurs in beheer van CPU Scheduler praat. Hy het bevestig dat die metode redelik werk en veilig is. Volgens ons ervaring was daar ook geen probleme daarmee nie.
Die werklike opdragte om die VM uit die Swap te verwyder Duncan Epping. Ek sal nie 'n gedetailleerde beskrywing herhaal nie, gee net 'n voorbeeld van die gebruik daarvan. Soos u in die skermkiekie kan sien, verdwyn Swap 'n rukkie na die uitvoering van die gespesifiseerde opdragte op die VM.
ESXi geheue bestuur wenke
Ten slotte, hier is 'n paar wenke wat jou sal help om probleme met VM-werkverrigting as gevolg van RAM te vermy:
- Vermy oorintekening van geheue in produktiewe groepe. Dit is wenslik om altyd ~20-30% vrye geheue in die groep te hê sodat DRS (en die administrateur) ruimte het om te maneuver, en VM's nie in Swap ingaan tydens migrasie nie. Moet ook nie die marge vir fouttoleransie vergeet nie. Dit is onaangenaam wanneer, wanneer een bediener misluk en die VM met HA herlaai word, sommige van die masjiene ook in Swap gaan.
- In hoogs gekonsolideerde infrastruktuur, probeer om NIE VM's met meer as die helfte van die gasheergeheue te skep nie. Dit sal weer DRS help om virtuele masjiene sonder enige probleme oor die groepbedieners te versprei. Hierdie reël is natuurlik nie universeel nie :).
- Kyk vir gasheergeheuegebruikalarm.
- Moenie vergeet om VMware Tools op die VM te installeer nie en moenie Ballooning afskakel nie.
- Oorweeg dit om Inter-VM TPS te aktiveer en Groot bladsye in VDI en toetsomgewings te deaktiveer.
- As die VM prestasieprobleme ondervind, kyk of dit geheue vanaf 'n afgeleë NUMA-nodus gebruik.
- Kry jou VM so vinnig as moontlik uit Swap! Onder andere, as die VM om ooglopende redes in Swap is, ly die bergingstelsel daaronder.
Dit is alles vir my oor RAM. Hieronder is 'n verwante artikel vir diegene wat in die besonderhede wil delf. Die volgende artikel sal aan storadzh gewy word.
nuttige skakels
Bron: will.com