VM-i jõudluse analüüs VMware vSphere'is. Osa 2: Mälumaht

Osa 1. CPU-st

Selles artiklis räägime mäluhalduse jõudlusnäidikutest (RAM) vSphere'is.
Mälu osas tundub kõik selgem kui protsessori puhul: kui VM-idel tekivad jõudlusprobleemid, on neid raske mitte märgata. Samas, kui need esinevad, on nendega palju keerulisem toime tulla. Kuid räägime kõigest järjekorras.

Veidi teooriat

Virtuaalmasinate mälu võetakse serveri mälust, kus VM-id töötavad. See on täiesti ilmselge :)). Kui serveri mälust ei piisa kõigi soovijate jaoks, hakkab ESXi rakendama mälu optimeerimise tehnikaid (memory reclamation techniques). Vastasel juhul kukuksid operatsioonisüsteemid VM-des välja, kuna juurdepääs RAM-ile ebaõnnestuks.

Milliseid tehnikaid rakendada, otsustab ESXi sõltuvalt mälu koormusest:

Mälu olek

Piir

Tegevused

High

400% minFree-st

Ülemise piiri saavutamisel jagatakse suured mälulehed väiksemateks (TPS töötab tavalises režiimis).

Kustuta

100% minFree-st

Suured mälulehed jagatakse väiksemateks, TPS töötab sundrežiimis.

Soft

64% minFree-st

TPS + Balloon

Hard

32% minFree-st

TPS + Compress + Swap

Madal

16% minFree-st

Compress + Swap + Block

Allikas

minFree onmälu, mis on vajalik hüperviisori töötamiseks.

Kuni ESXi 4.1 välja arvatud oli minFree vaikimisi fikseeritud — 6% serveri mälu mahust (seda protsenti sai muuta ESXi-s valikuga Mem.MinFreePct). Hilisemates versioonides, kuna serverite mälu mahud kasvasid, arvutatakse minFree vastavalt hosti mälumahule, mitte fikseeritud protsendina.

Vaikimisi minFree väärtus arvutatakse järgmiselt:

Mälu protsent, mis reserveeritakse minFree jaoks

Mälu vahemik

6%

0-4 GB

4%

4-12 GB

2%

12-28 GB

1%

Jäänud mälu

Allikas

Näiteks serveri, millel on 128 GB RAM, minFree väärtus oleks järgmine:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Tegelik väärtus võib erineda paarisaja MB võrra, sõltuvalt serverist ja mälust.

Mälu protsent, mis reserveeritakse minFree jaoks

Mälu vahemik

128 GB jaoks väärtus

6%

0-4 GB

245,76 MB

4%

4-12 GB

327,68 MB

2%

12-28 GB

327,68 MB

1%

Jäänud mälu (100 GB)

1024 MB

Tavaliselt võib tootmisseadistuste puhul pidada kõrget olekut normaalseks. Testimise ja arendamise seadistuste puhul võivad aktsepteeritavad olla seisundid Clear/Soft. Kui hostis jääb minFree-st vähem kui 64%, siis VM-id, mis sellel töötavad, kogevad kindlasti jõudlusprobleeme.

Iga seisundis rakendatakse teatud mälu tagasiatchimise tehnikasid, alustades TPS-ist, mis praktiliselt ei mõjuta VM-i jõudlust, ja lõpetades vahetusse kuuluvate tehnoloogiatega. Räägin neist lähemalt.

Läbipaistev lehe jagamine (TPS). TPS on, ütleme nii, virtuaalsete masinate mälulehtede deplitseerimine serveris.

ESXi otsib virtuaalsete masinate identseid mälu lehti, arvestades ja võrreldes lehe hash-summat, ning eemaldab korduvad lehed, asendades need viidete kaudu sama lehega füüsilises mälus serveris. Selle tulemusena väheneb füüsilise mälu tarbimine ja on võimalik saavutada teatud mälureetmine praktiliselt ilma jõudluse vähenemiseta.

Allikas

See mehhanism töötab ainult 4 Kb (väikeste lehtede) mälulehtede puhul. 2 Mb (suurte lehtede) suurusega lehti hüperviisor ei püüa isegi deplitseerida: identsete lehtede leidmise tõenäosus sellise suuruse puhul ei ole suur.

Vaikesätetena eraldab ESXi mälu suurtele lehtedele. Suurte lehtede jagamine väikesteks algab, kui saavutatakse kõrge oleku lävi, ja toimub sundimise teel, kui saavutatakse selge olek (vt hüperviisori olekute tabelit).

Kui soovite, et TPS alustaks tööd, ilma et ootate hosti mälu täitumist, peate ESXi Täiustatud valikutes seadmise väärtuse “Mem.AllocGuestLargePage” seadma 0-le (vaikesättega 1). Siis on suured lehtede mälu virtualiseerimiseks välja lülitatud.

Alates 2014. aasta detsembrist on kõigis ESXi versioonides TPS VM-ide vahel vaikesätetena välja lülitatud, kuna leiti haavatavus, mis teoreetiliselt võimaldab ühe VM-i kaudu pääseda teise VM-i mälu. Üksikasjad siin. Teave TPS haavatavuse praktilise kasutamise rakendamise kohta ei ole mulle teada.

TPS poliitikat kontrollitakse läbi täiustatud valiku “Mem.ShareForceSalting” ESXi-s:
0 — Inter-VM TPS. TPS töötab erinevate VM-ide lehtede puhul;
1 — TPS VM-ide puhul, millel on sama “sched.mem.pshare.salt” väärtus VMX-is;
2 (vaikesättena) — Intra-VM TPS. TPS töötab lehtede vahel VM-i sees.

Mõistlik on välja lülitada suured lehed ja lubada Inter-VM TPS testkeskkondades. Seda võib kasutada ka keskkondades, kus on suur hulk sarnaseid VM-e. Näiteks VDI keskkondades võib füüsilise mälu kokkuhoid ulatuda kümnetesse protsentidesse.

Mälu balloonimine. Ballooning ei ole enam nii kahjutu ja läbipaistev VM-tehnika nagu TPS. Kuid kui seda õigesti rakendada, on Ballooninguga võimalik elada ja isegi töötada.

Koos VMware Toolsiga installitakse VM-ile spetsiaalne draiver, mida nimetatakse Balloon Driveriks (samuti vmmemctl). Kui hüpervisoril hakkab füüsilisest mälust puudu, siseneb ta Soft-seisundisse, kus ESXi palub VM-l tagasi anda kasutamata operatiivmälu läbi selle Balloon Driveri. Draiver töötab opsüsteemi tasemel ja küsib vabadele andmetele operatsioonisüsteemist. Hüpervisor näeb, millised füüsilise mälu lehed on Balloon Driveri poolt hõivatud, võtab mälumahtu virtuaalmasinalt ja tagastab selle hostile. Operatsioonisüsteemi tööga ei esine probleeme, kuna mälu on opsüsteemi tasemel Balloon Driveri poolt hõivatud. Vaikimisi võib Balloon Driver võtta kuni 65% VM-i mälust.

Kui VM-il ei ole installitud VMware Toolsit või on Ballooning välja lülitatud (soovitan mitte teha, kuid on olemas KB:), hüpervisor läheb kohe rangemate mälu ära võtmiseks mõeldud tehnikate juurde. Järeldus: jälgige, et VMware Tools oleks VM-is installitud.

Balloon Driveri tööd saab kontrollida opsüsteemist läbi VMware Toolsi.

Mälu kokkusurumine. Seda tehnikat kasutatakse, kui ESXi jõuab Hard-seisundisse. Nagu nimigi ütleb, üritab ESXi suruda 4 KB suurused operatiivmälu lehed 2 KB suurusteks, vabastades seeläbi veidi ruumi serveri füüsilises mälus. See tehnika suurendab oluliselt juurdepääsu aega VM-i operatiivmälu lehtede sisule, kuna leht tuleb eelnevalt dekompressida. Vahel ei õnnestu kõiki lehti kokku suruda ja kogu protsess võtab teatud aja. Seetõttu ei ole see tehnika praktikas eriti tõhus.

Mälu vahetus. Pärast lühikest mälu kokkusurumise faasi läheb ESXi praktiliselt vältimatult (kui VM-e ei ole teisaldatud teistele hostidele või välja lülitatud) vahetusse. Ja kui mälu on jäänud väga vähe (madal seisund), siis hüpervisor lõpetab ka VM-idele mälulehtede eraldamise, mis võib põhjustada probleeme VM-i külaliste opsüsteemides.

Nii, kuidas Swapping töötab. Virtuaalmasina aktiveerimisel luuakse selle jaoks fail laiendiga .vswp. Suuruselt on see võrdne VM-i mittereserveeritud mälu osaga: see on erinevus konfigureeritud ja reserveeritud mälu vahel. Swappingu korral laadib ESXi virtuaalmasina mälu leheküljed sellesse faili ja hakkab töötama selle abil füüsilise mäluga serveris. Loomulikult on selline „mälu” mitmeid korraldusi aeglasem kui tõeline, isegi kui .vswp asub kiirel salvestusseadmel.

Erinevalt Ballooning'ust, kus VM-ilt võetakse kasutamata leheküljed, võivad Swappingu ajal ketta peale minna leheküljed, mida OS või rakendused aktiivselt kasutavad. Selle tulemusel langeb VM-i jõudlus tõsiselt, kuni see hakkab külmuma. VM töötab formaalselt ja seda saab vähemalt õigesti OS-ist välja lülitada. Kui te olete kannatlik 😉

Kui VM-id on Swap-i läinud — see ei ole normaalne olukord, mille tekkimist on parem vältida.

Virtuaalmasina mälu jõudluse peamised näitajad

Nüüd oleme jõudnud põhiteemani. VM-s mälu seisundi jälgimiseks on järgmised näitajad:

Active — näitab mälumahtu (KB), millega VM pääses eelmise mõõtmisperioodi jooksul.

Kasutus — sama, mis Aktiivne, kuid protsentides konfigureeritud mälu suurusest VM-is. Arvutatakse järgmise valemi järgi: aktiivne ÷ virtuaalmasina konfigureeritud mälu suurus.
Kõrge kasutuse ja aktiivse näitaja puhul ei ole see tingimata jõudlusprobleemide märk. Kui VM kasutab mälu intensiivselt (minimaalsetel tasemetel, pääseb sellele juurde), ei tähenda see, et mälu jääb väheks. Pigem on see põhjus vaadata, mis toimub OS-is.
VM-ide jaoks on olemas standardne Alarm mälu kasutuse kohta:

Jagatud — virtuaalmasina mälu maht, mis on deduplikatsioonitud TPS abil (kas VM sees või VM-ide vahel).

Antud — füüsilise mälu maht hostis (KB), mis on antud VM-ile. Kaasa arvatud jagatud.

Tarbitud (Antud — Jagatud) — füüsilise mälu (KB) maht, mida VM tarbib hostist. Ei hõlma jagatud.

Kui osa VM-i mälust antakse mitte füüsilisest mälust hostis, vaid swap-failist või mälu on võetud VM-ilt Balloon Driveri kaudu, ei arvestata seda mahtu Antud ja Tarbitud.
Kõrged Granted ja Consumed väärtused on täiesti normaalsed. Operatsioonisüsteem võtab järk-järgult mälu hüperviisorilt ja ei anna seda tagasi. Aja jooksul, kui virtuaalmasin (VM) aktiivselt töötab, jõuavad need arvestite väärtused konfigureeritud mälu mahule ja seal püsivad.

Null — operatiivmälu maht (KByte), mis sisaldab nullide väärtusi. Selline mälu loetakse hüperviisori poolt vabaks ja võib olla antud teistele virtuaalmashinatele. Pärast seda, kui külalisoperatsioonisüsteem on kirjutatud midagi nullitud mällu, muutub see Consumed-iks ja ei naase enam tagasi.

Reserved Overhead — operatiivmälu maht (KByte), mis on hüperviisori poolt reserveeritud VM-i tööks. See on väike maht, kuid see peab olema hostis olemas, vastasel juhul VM ei käivitu.

Balloon — operatiivmälu maht (KByte), mis on VM-ilt välja võetud Balloon Driver'i abil.

Compressed — operatiivmälu maht (KByte), mille õnnestus tihendada.

Swapped — operatiivmälu maht (KByte), mis serveris füüsilise mälu puudumisel tuli kettale.
Balloon ja ülejäänud mälu tagastamise tehnikate arvestid on null.

Nii näeb välja graafik mälu arvestitega normaalselt töötavale VM-ile, millel on 150 GB operatiivmälu.

Alloleval graafikul on VM-il selged probleemid. Graafiku all on näha, et sellele VM-ile on kasutatud kõiki kirjeldatud mälu tehnikaid. Balloon on selle VM-i jaoks oluliselt suurem kui Consumed. Tegelikult on VM pigem surnud kui elus.

ESXTOP

Nagu CPU puhul, kui soovime operatiivselt hinnata olukorda hostis ja selle dünaamikat kuni 2-sekundiliste intervallidega, tasub kasutada ESXTOP-i.

ESXTOP mäluekran kuvatakse klahviga „m” ja näeb välja järgmine (valitud väljad B,D,H,J,K,L,O):

Meie jaoks huvitavad on järgmised parameetrid:

Mem overcommit avg — keskmine mälu ülepuhutud väärtus hostis 1, 5 ja 15 minuti jooksul. Kui see on üle nulli, on see põhjus vaadata, mis toimub, kuid see ei ole alati märk probleemidest.

Ridades PMEM/MB ja VMKMEM/MB — teave serveri füüsilise mälu ja VMkerneli poolt saadaval oleva mälu kohta. Siin on huvitav näha väärtust minfree (MB-des) ja hosti mälu seisundit (meie juhul high).

Reas NUMA/MB võib näha operatiivmälu jaotust NUMA-sõlmedes (soketites). Antud näites on jaotus ebavõrdne, mis ei ole tegelikult väga hea.

Edasi on üldine statistika serveri kohta mälu taastamise tehnikate kohta:

PSHARE/MB — see on TPS statistika;

SWAP/MB — Swap'i kasutamise statistika;

ZIP/MB — mälu lehekülgede kokkusurumise statistika;

MEMCTL/MB — Balloon Driver'i kasutamise statistika.

Konkreetsete VM-ide kohta võib meid huvitada järgmine teave. VM-ide nimed olen varjanud, et mitte publikule segadust tekitada :P. Kui mõõt ESXTOP on sarnane vSphere'i loendurile, siis toon vastava loenduri.

MEMSZ — mälu suurus, mis on VM-ile konfigureeritud (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.

GRANT — granted MB-des.

TCHD — aktiivne MB-des.

MCTL? — kas VM-l on Balloon Driver seadistatud.

MCTLSZ — Balloon MB-des.

MCTLGT — protsessori mälu (MB), mille ESXi soovib VM-ilt läbi Balloon Driver tagasi võtta (Memctl Target).

MCTLMAX — maksimaalne protsessori mälu (MB), mille ESXi võib VM-ilt läbi Balloon Driver tagasi võtta.

SWCUR — praegune protsessori mälu (MB), mis on VM-ile anda Swap-failist.

SWGT — protsessori mälu (MB), mille ESXi soovib VM-ile anda Swap-failist (Swap Target).

Samuti saab ESXTOP'i kaudu vaadata põhjalikumat teavet NUMA-topoloogia kohta. Selle jaoks tuleb valida väljad D,G:

NHN – NUMA sõlmed, kus VM asub. Siin saab kohe märgata laiu VM-e, mis ei mahu ühe NUMA sõlme sisse.

NRMEM – kui palju megabaite mälu VM kaugelt NUMA sõlmest võtab.

NLMEM – kui palju megabaite mälu VM kohalikust NUMA sõlmest võtab.

N%L – protsent VM mälast kohalikul NUMA sõlmel (kui alla 80% — võivad tekkida jõudlusprobleemid).

Mälu hüperviisoris

Kui hüperviisori CPU loendurid ei esinda tavaliselt erilist huvi, siis mälu puhul on olukord vastupidine. Kõrge mälu kasutamine VM-is ei pruugi alati tähendada jõudlusprobleemide olemasolu, kuid kõrge mälu kasutamine hüperviisoril aktiveerib mälu juhtimise tehnikate töö ja kutsub esile VM-i jõudlusprobleemid. Peame jälgima Host Memory Usage alarmide eest, et vältida VM-i sattumist Swap'i.

Unswap

Kui VM satub Swap'i, väheneb selle jõudlus oluliselt. Ballooningu ja kokkusurumise jäljed kaovad kiiresti pärast vabade protsessori mälu tekkimist hostis, kuid tagasi naasmiseks Swap'ist protsessori mällu ei kiirusta virtuaalne masin üldse.
Enne versiooni ESXi 6.0 oli ainus usaldusväärne ja kiire viis VM-i Swap'ist välja viia taaskäivitamine (täpsemalt konteineri väljalülitamine ja sisselülitamine). Alates ESXi 6.0-st ilmus küll mitte täiesti ametlik, kuid töötav ja usaldusväärne viis VM-i Swap'ist välja viia. Ühel konverentsil sain suhelda ühe VMware'i inseneriga, kes vastutab CPU ajakava eest. Ta kinnitas, et see meetod on täiesti töötav ja ohutu. Meie praktikas ei ole sellega ka mingeid probleeme märgatud.

Ehkki käsklused VM-i välja viimiseks Swap'ist kirjeldas Duncan Epping. Ma ei hakka kordama üksikasjalikku kirjeldust, lihtsalt toon näite selle kasutamisest. Nagu ekraanipildilt näha, kaob mõne aja pärast pärast näidatud käsu täitmist Swap VM-ist.

Nõuanded RAM-i haldamiseks ESXi-s

Lõpetuseks toon välja mõned nõuanded, mis aitavad teil vältida VM-i jõudlusprobleeme RAM-i tõttu:

• Ärge lubage RAM-i üleallokatsiooni tootmisklastrites. Soovitav on alati hoida ~20-30% vaba mälu klastris, et DRS-il (ja administraatoril) oleks manööverdusruumi ja et VM-id ei läheks Swap'i migreerimise ajal. Samuti ärge unustage varu tõrketaluvuseks. Ebamugav on, kui ühe serveri tõrke korral ja VM-ide taaskäivitamisel HA kaudu lähevad osa masinaid veel Swap'i.
• Kõrge konsolideerimisega infrastruktuurides püüdke mitte luua VM-e, mille mälu ületab poole hosti mälu. See aitab DRS-il ilma probleemideta jaotada virtuaalmasinad klastris serverite vahel. See reegel ei ole muidugi universaalne :).
• Jälgige hosti mälukasutuse alarmi.
• Ärge unustage installida VM-idesse VMware Tools'i ja ärge lülitage Ballooningut välja.
• Kaaluge Inter-VM TPS-i lubamist ja Suurte Lehekülgede välja lülitamist VDI ja testkeskkondades.
• Kui VM-il on jõudlusprobleeme, kontrollige, kas see kasutab mälurakendust kaugel NUMA sõlmes.
• Viige VM Swap'ist välja nii kiiresti kui võimalik! Peale selle, kui VM on Swap's, kannatab ilmselgelt ka ANDMEKESKUS.

Sellel ongi kõik RAM-i kohta. Allpool on artiklid teemal neile, kes soovivad süveneda detailidesse. Järgmine artikkel räägib salvestusest.

Kasulikud lingidhttp://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/
http://www.yellow-bricks.com/2013/06/14/how-does-mem-minfreepct-work-with-vsphere-5-0-and-up/
https://www.vladan.fr/vmware-transparent-page-sharing-tps-explained/
http://www.yellow-bricks.com/2016/06/02/memory-pages-swapped-can-unswap/
https://kb.vmware.com/s/article/1002586
https://www.vladan.fr/what-is-vmware-memory-ballooning/
https://kb.vmware.com/s/article/2080735
https://kb.vmware.com/s/article/2017642
https://labs.vmware.com/vmtj/vmware-esx-memory-resource-management-swap
https://blogs.vmware.com/vsphere/2013/10/understanding-vsphere-active-memory.html
https://www.vmware.com/support/developer/converter-sdk/conv51_apireference/memory_counters.html
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-monitoring-performance-guide.pdf

Allikas: habr.com