Selles artiklis räägime muutmälu (RAM) jõudlusloenduritest vSphere'is.
Tundub, et mäluga on kõik selgem kui protsessoriga: kui VM-is tekivad jõudlusprobleemid, on neid raske mitte märgata. Aga kui need ilmuvad, on nendega palju keerulisem toime tulla. Aga kõigepealt asjad kõigepealt.
Natuke teooriat
Virtuaalsete masinate RAM võetakse selle serveri mälust, kus virtuaalsed masinad töötavad. See on ilmselge :). Kui serveri RAM-ist kõigile ei piisa, hakkab ESXi kasutama mälu taastamise tehnikaid. Vastasel juhul jooksevad VM-i operatsioonisüsteemid kokku RAM-i juurdepääsuvigade tõttu.
ESXi otsustab, milliseid tehnikaid kasutada sõltuvalt RAM-i koormusest:
Mälu olek
Piir
Tegevus
Suur
400% minFree'ist
Pärast ülempiiri saavutamist jagatakse suured mälulehed väikesteks (TPS töötab standardrežiimis).
Puhasta valikud
100% minFree'ist
Suured mälulehed jagatakse väikesteks, TPS on sunnitud.
Pehme
64% minFree'ist
TPS + õhupall
Raske
32% minFree'ist
TPS + tihendamine + vahetamine
Madal
16% minFree'ist
Tihenda + vaheta + blokeeri
minFree on hüperviisori töötamiseks vajalik RAM.
Kuni ESXi 4.1-ni (kaasa arvatud) oli minFree vaikimisi fikseeritud - 6% serveri RAM-ist (protsenti saab muuta ESXi valiku Mem.MinFreePct kaudu). Hilisemates versioonides hakati serverite mälu kasvu tõttu minFree'i arvutama hosti mälumahu põhjal, mitte fikseeritud protsendiväärtusena.
MinFree väärtus (vaikimisi) arvutatakse järgmiselt:
MinFree jaoks reserveeritud mälu protsent
Mälu ulatus
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Järelejäänud mälu
Näiteks 128 GB muutmäluga serveri puhul on MinFree väärtus järgmine:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Tegelik väärtus võib sõltuvalt serverist ja RAM-ist erineda paarisaja MB võrra.
MinFree jaoks reserveeritud mälu protsent
Mälu ulatus
Väärtus 128 GB kohta
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Järelejäänud mälu (100 GB)
1024 MB
Tavaliselt saab produktiivsete puistute puhul normaalseks pidada ainult kõrget seisundit. Testimis- ja arendusstendi puhul võib selge/pehme olek olla vastuvõetav. Kui hosti RAM on alla 64% MinFree, on sellel töötavatel VM-idel kindlasti jõudlusprobleeme.
Igas olekus kasutatakse teatud mälu taastamise tehnikaid, alustades TPS-ist, mis praktiliselt ei mõjuta VM-i jõudlust, kuni vahetamiseni. Ma räägin teile neist lähemalt.
Läbipaistev lehe jagamine (TPS). TPS on jämedalt öeldes serveri virtuaalmasinate RAM-i lehtede dubleerimine.
ESXi otsib identseid virtuaalmasina RAM-i lehti, loendades ja võrreldes lehtede räsisummat, ning eemaldab dubleerivad lehed, asendades need viidetega samale lehele serveri füüsilises mälus. Selle tulemusena väheneb füüsilise mälu tarbimine ja mõningane mälu ületellimus on saavutatav, ilma et see mõjutaks jõudlust.
See mehhanism töötab ainult 4 KB suuruste mälulehtede puhul (väikesed lehed). Hüpervisor ei ürita isegi 2 MB suurusi lehti (suured lehed) dubleerida: võimalus leida sellises suuruses identseid lehti pole suur.
Vaikimisi eraldab ESXi mälu suurtele lehtedele. Suurte lehtede jagamine väikesteks lehtedeks algab siis, kui on saavutatud kõrge olekulävi, ja sunnitakse seda, kui on saavutatud tühjendus (vt hüperviisori olekutabelit).
Kui soovite, et TPS hakkaks töötama ootamata hosti RAM-i täitumist, peate määrama väärtuse jaotises Advanced Options ESXi "Mem.AllocGuestLargePage" 0-le (vaikimisi 1). Seejärel keelatakse suurte mälulehtede eraldamine virtuaalsetele masinatele.
Alates 2014. aasta detsembrist on kõigis ESXi väljaannetes VM-idevaheline TPS vaikimisi keelatud, kuna leiti haavatavus, mis võimaldab teoreetiliselt ühel VM-il pääseda juurde teise VM-i RAM-ile. Üksikasjad siin. Ma ei ole kohanud teavet TPS-i haavatavuse ärakasutamise praktilise rakendamise kohta.
TPS-i poliitikat juhitakse täiustatud valiku kaudu "Mem.ShareForceSalting" ESXi puhul:
0 – Inter-VM TPS. TPS töötab erinevate VM-ide lehtede jaoks;
1 – TPS VM-i jaoks, millel on VMX-is sama "sched.mem.pshare.salt" väärtus;
2 (vaikimisi) – VM-sisene TPS. TPS töötab VM-i lehtede puhul.
Kindlasti on mõttekas keelata suured lehed ja lubada katsestenditel Inter-VM TPS. Seda saab kasutada ka suure hulga sarnaste VM-idega stendide jaoks. Näiteks VDI-ga stendidel võib füüsilise mälu kokkuhoid ulatuda kümnetesse protsentidesse.
Mälu õhupallid. Õhupallitamine pole VM-i operatsioonisüsteemi jaoks enam nii kahjutu ja läbipaistev tehnika kui TPS. Kuid õige kasutamise korral saate Ballooninguga elada ja isegi töötada.
Koos Vmware Toolsiga installitakse VM-i spetsiaalne draiver nimega Balloon Driver (teise nimega vmmemctl). Kui hüperviisori füüsiline mälu hakkab otsa saama ja lülitub pehmesse olekusse, palub ESXi VM-il selle Balloon Driveri kaudu kasutamata RAM-i tagasi nõuda. Draiver omakorda töötab operatsioonisüsteemi tasemel ja nõuab sellelt vaba mälu. Hüpervisor näeb, millised füüsilise mälu leheküljed Balloon Driver on hõivanud, võtab virtuaalmasinast mälu ja tagastab selle hostile. OS-i tööga probleeme pole, kuna OS-i tasemel hõivab mälu Balloon Driver. Vaikimisi võib Balloon Driver võtta kuni 65% VM-i mälust.
Kui VMware tööriistad pole VM-i installitud või Ballooning on keelatud (ma ei soovita seda, kuid on :), lülitub hüperviisor koheselt mälu eemaldamise rangematele tehnikatele. Järeldus: veenduge, et VMware tööriistad oleksid VM-is.
Balloon Driveri tööd saab kontrollida OS-ist VMware Toolsi kaudu.
Mälu tihendamine. Seda tehnikat kasutatakse siis, kui ESXi jõuab kõvasse olekusse. Nagu nimigi viitab, üritab ESXi tihendada 4KB RAM-i lehe 2KB-ks, vabastades sellega serveri füüsilises mälus ruumi. See meetod pikendab oluliselt juurdepääsuaega VM RAM-i lehtede sisule, kuna leht tuleb esmalt lahti pakkida. Mõnikord ei saa kõiki lehti tihendada ja protsess ise võtab aega. Seetõttu pole see tehnika praktikas kuigi tõhus.
Mälu vahetamine. Pärast lühikest mälu tihendamise etappi lülitub ESXi peaaegu vältimatult (kui VM-id pole teistesse hostidesse kolinud või pole välja lülitatud) vahetusele. Ja kui mälu on alles väga vähe (madal olek), siis lõpetab hüperviisor ka VM-ile mälulehtede eraldamise, mis võib tekitada probleeme VM-i külalis-OS-is.
Vahetus käib nii. Kui lülitate virtuaalse masina sisse, luuakse selle jaoks fail laiendiga vswp. See on suuruselt võrdne VM-i reserveerimata RAM-iga: see on erinevus konfigureeritud ja reserveeritud mälu vahel. Kui Swapping töötab, vahetab ESXi virtuaalmasina mälulehed sellesse faili ja hakkab serveri füüsilise mälu asemel sellega töötama. Muidugi on selline "RAM" mälu mitu suurusjärku aeglasem kui pärismälu, isegi kui .vswp on kiirel salvestusel.
Erinevalt Ballooningist, kui kasutamata lehed võetakse VM-st, saab vahetamisega lehti, mida OS või VM-is olevad rakendused aktiivselt kasutavad, teisaldada kettale. Selle tulemusena langeb VM-i jõudlus külmumiseni. VM töötab ametlikult ja selle saab OS-ist vähemalt korralikult keelata. Kui oled kannatlik 😉
Kui VM-id on vahetusse läinud, on see hädaolukord, mida on võimalusel kõige parem vältida.
Põhilised virtuaalse masina mälu jõudluse loendurid
Nii et jõudsime põhiasjani. VM-i mälu oleku jälgimiseks on järgmised loendurid.
aktiivne — näitab RAM-i hulka (KB), millele virtuaalmasin eelmisel mõõtmisperioodil juurde pääses.
Kasutus — sama, mis Active, kuid protsendina VM-i konfigureeritud RAM-ist. Arvutatakse järgmise valemi abil: aktiivne ÷ virtuaalmasina konfigureeritud mälumaht.
Vastavalt High Usage ja Active ei ole alati VM-i jõudlusprobleemide näitaja. Kui VM kasutab agressiivselt mälu (vähemalt sellele juurde pääseb), ei tähenda see, et mälu pole piisavalt. Pigem on see põhjus vaadata OS-is toimuvat.
VM-ide jaoks on olemas standardne mälukasutuse häire:
Jagatud — TPS-i abil dubleeritud VM-i RAM-i hulk (VM-i sees või VM-ide vahel).
Antakse — VM-ile eraldatud hosti füüsilise mälu (KB) maht. Lubab jagatud.
Tarbitud (Antud – jagatud) – füüsilise mälu maht (KB), mida VM hostilt tarbib. Ei sisalda jagatud.
Kui osa VM-i mälust ei anta hosti füüsilisest mälust, vaid vahetusfailist või kui mälu võetakse VM-ist Balloon Driveri kaudu, ei võeta seda summat jaotises Granted and Consumed arvesse.
Kõrged antud ja tarbitud väärtused on täiesti normaalsed. Operatsioonisüsteem võtab hüperviisorilt järk-järgult mälu ega anna seda tagasi. Aja jooksul lähenevad aktiivselt töötavas virtuaalses masinas nende loendurite väärtused konfigureeritud mälu mahule ja jäävad sinna.
Null — VM RAM-i hulk (KB), mis sisaldab nulle. Sellist mälu loeb hüperviisor vabaks ja seda saab anda teistele virtuaalsetele masinatele. Kui külalis-OS on midagi nullitud mällu kirjutanud, läheb see kausta Consumed ega naase tagasi.
Reserveeritud Üldkulud — VM-i RAM-i hulk (KB), mille hüperviisor on reserveerinud VM-i tööks. See on väike summa, kuid see peab hostis saadaval olema, vastasel juhul VM ei käivitu.
Õhupall — RAM-i hulk (KB), mis on Balloon Driveri abil virtuaalmasinast eemaldatud.
Kokkusurutud — kokkusurutud RAM-i hulk (KB).
Vahetasime — RAM-i maht (KB), mis serveri füüsilise mälu puudumise tõttu kettale kolis.
Õhupallide ja muude mälu taastamise tehnikate loendurid on nullis.
Selline näeb graafik välja normaalselt töötava 150 GB muutmäluga VM-i mäluloendurite puhul.
Alloleval graafikul on VM-il ilmsed probleemid. Graafiku all näete, et selle VM-i jaoks kasutati kõiki kirjeldatud RAM-iga töötamise tehnikaid. Selle VM-i õhupall on palju suurem kui Consumed. Tegelikult on VM rohkem surnud kui elus.
ESXTOP
Nagu CPU puhul, peaksime kasutama ESXTOP-i, kui tahame kiiresti hinnata hosti olukorda ja selle dünaamikat kuni 2-sekundilise intervalliga.
ESXTOP-mälu ekraan avatakse klahviga "m" ja see näeb välja järgmine (valitud on väljad B,D,H,J,K,L,O):
Järgmised parameetrid pakuvad meile huvi:
Mem overcommit avg — mälu ületellimise keskmine väärtus hostis 1, 5 ja 15 minuti jooksul. Kui see on üle nulli, on see põhjus toimuvat vaadata, kuid mitte alati probleemide näitaja.
Ridades PMEM/MB и VMKMEM/MB — teave serveri füüsilise mälu ja VMkerneli käsutuses oleva mälu kohta. Siin on huvitavate asjade hulgas näha minfree väärtust (MB), hosti olekut mälus (meie puhul kõrget).
Järjekorras NUMA/MB näete RAM-i jaotust NUMA sõlmede (pesade) vahel. Selles näites on jaotus ebaühtlane, mis pole põhimõtteliselt kuigi hea.
Järgmine on mälu taastamise tehnikate üldine serveristatistika:
PSHARE/MB — see on TPS-i statistika;
VAHETA/MB — vahetustehingu kasutamise statistika;
ZIP/MB — mälulehtede tihendamise statistika;
MEMCTL/MB — Balloon Driveri kasutamise statistika.
Üksikute VM-ide puhul võib meid huvitada järgmine teave. VM-ide nimed peitsin ära, et publikut mitte segadusse ajada :). Kui ESXTOP-i mõõdik on sarnane vSphere'i loenduriga, esitan vastava loenduri.
MEMSZ — VM-is konfigureeritud mälu maht (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + puutumata.
TOETUS — antud MB-s.
TCHD — Aktiivne MBaitis.
MCTL? — kas VM-i on installitud Balloon Driver.
MCTLSZ — Õhupall MB-le.
MCTLGT — RAM-i hulk (MBytes), mille ESXi soovib Balloon Driveri (Memctl Target) kaudu virtuaalmasinast eemaldada.
MCTLMAX — maksimaalne RAM-i hulk (MBaite), mille ESXi saab Balloon Driveri kaudu VM-st eemaldada.
SWCUR — vahetusfailist VM-ile eraldatud praegune RAM-i hulk (MBaite).
S.W.G.T. — RAM-i hulk (MBytes), mille ESXi soovib vahetusfailist (Swap Target) VM-ile anda.
ESXTOP-i kaudu saate vaadata ka üksikasjalikumat teavet VM-i NUMA-topoloogia kohta. Selleks valige väljad D, G:
VÄIKE – NUMA sõlmed, millel VM asub. Siin on kohe märgata lai vm, mis ühele NUMA sõlmele ei mahu.
NRMEM – mitu megabaiti mälu VM kaug-NUMA-sõlmest võtab.
NLMEM – mitu megabaiti mälu võtab VM kohalikust NUMA-sõlmest.
N%L – VM-mälu protsent kohalikus NUMA-sõlmes (kui see on alla 80%, võivad tekkida jõudlusprobleemid).
Mälu hüperviisoril
Kui tavaliselt ei paku hüperviisori CPU loendurid erilist huvi, siis mäluga on olukord vastupidine. VM-i suur mälukasutus ei viita alati jõudlusprobleemile, kuid kõrge mälukasutus hüperviisoris käivitab mäluhaldustehnikad ja põhjustab probleeme VM-i jõudlusega. Peate jälgima hostimälu kasutamise häireid ja vältima VM-ide sattumist vahetusse.
Tühista vahetus
Kui VM satub vahetusse, väheneb selle jõudlus oluliselt. Ballooning ja tihendamise jäljed kaovad kiiresti pärast vaba RAM-i ilmumist hosti, kuid virtuaalmasin ei kiirusta Swapist serveri RAM-i naasma.
Enne ESXi 6.0 oli ainus usaldusväärne ja kiire viis VM-i Swapist eemaldamiseks taaskäivitamine (täpsemalt konteineri välja-/sisselülitamine). Alates ESXi 6.0-st, ehkki mitte täiesti ametlik, on ilmunud töötav ja usaldusväärne viis VM-i eemaldamiseks Swapist. Ühel konverentsil sain vestelda ühe CPU Scheduleri eest vastutava VMware inseneriga. Ta kinnitas, et meetod on üsna toimiv ja ohutu. Meie kogemuse kohaselt ei olnud sellega ka probleeme.
Tegelikud käsud VM-i Swapist eemaldamiseks Duncan Epping. Ma ei korda üksikasjalikku kirjeldust, toon lihtsalt näite selle kasutamisest. Nagu näete ekraanipildil, kaob mõni aeg pärast määratud käsu täitmist VM-i Swap.
Näpunäiteid ESXi RAM-i haldamiseks
Lõpuks on siin mõned näpunäited, mis aitavad teil vältida RAM-i tõttu probleeme VM-i jõudlusega.
- Vältige tootlikes klastrites RAM-i ületellimist. Klastris on soovitav alati olla ~20-30% vaba mälu, et DRS-il (ja administraatoril) oleks manööverdamisruumi ja VM-id ei läheks migratsiooni käigus Swapi. Ärge unustage ka tõrketaluvuse marginaali. On ebameeldiv, kui ühe serveri tõrke korral ja VM taaskäivitamisel HA abil lähevad mõned masinad ka vahetusse.
- Väga konsolideeritud infrastruktuurides MITTE luua VM-e, mille mälu on suurem kui pool hostimälust. See jällegi aitab DRS-il virtuaalmasinaid klastriserverite vahel ilma probleemideta levitada. See reegel ei ole muidugi universaalne :).
- Jälgige hosti mälu kasutamise häiret.
- Ärge unustage VM-i installida VMware Tools ja ärge lülitage Ballooning välja.
- Kaaluge Inter-VM TPS-i lubamist ja suurte lehtede keelamist VDI- ja testkeskkondades.
- Kui VM-il on jõudlusprobleeme, kontrollige, kas see kasutab kaug-NUMA-sõlme mälu.
- Eemaldage Swapist VM-id nii kiiresti kui võimalik! Muuhulgas, kui VM on Swapis, kannatab arusaadavatel põhjustel salvestussüsteem.
See on minu jaoks RAM-i kohta kõik. Allpool on seotud artiklid neile, kes soovivad süveneda. Järgmine artikkel on pühendatud storajale.
Kasulikud lingid
Allikas: www.habr.com