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

Osa 1. CPU-st

Selles artiklis räägime vSphere'is töötava RAM-i jõudlusloenduritest.
Mälu osas tundub kõik olevat selgem, kui protsessori osas: kui VM-ides esinevad jõudlusprobleemid, on neid raske mitte märgata. Kui need aga ilmnevad, on nende lahendamine palju keerulisem. Aga võtame kõik etappid järjest.

Natuke teooriat

Virtuaalmasinate töömälu tuleb serveri mälust, millel masinad töötavad. See on täiesti arusaadav:). Kui serveri töömälu ei piisa kõigile soovijatele, hakkab ESXi rakendama mälu optimeerimise tehnikaid (memory reclamation techniques). Vastasel juhul kukuksid operatsioonisüsteemid mälu juurde pääsemise vigade tõttu.

Milliseid tehnikaid rakendada, otsustab ESXi mälu koormuse põhjal:

Mälu seisund

Piir

Toimingud

Kõrge

400% minFree'ist

Peale ülemise piiri saavutamist jagatakse suured mälulehed väikesteks (TPS töötab tavalises režiimis).

Puhasta

100% minFree'ist

Suured mälulehed jagatakse väikesteks, TPS töötab sundimisega.

Pehme

64% minFree'ist

TPS + Balloon

Kõva

32% minFree'ist

TPS + Compress + Swap

Madal

16% minFree'ist

Kao + Vahetus + Plokk

Allikas

minFree — see on mälu, mis on vajalik hüperviisori tööks.

Kuni ESXi 4.1 oli minFree vaikimisi fikseeritud — 6% serveri mälust (protsenti sai muuta valiku Mem.MinFreePct kaudu ESXi-s). Hilisemates versioonides, arvestades serverite mälu suurenenud mahtu, arvutatakse minFree hosti mälust, mitte kui fikseeritud protsent.

minFree (vaikimisi) väärtus arvutatakse järgmiselt:

Protsent mälust, mis on reserveeritud minFree jaoks

Mälupiirang

6%

0-4 GB

4%

4-12 GB

2%

12-28 GB

1%

Järelejäänud mälu

Allikas

Näiteks, 128 GB RAM-iga serveri 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 paarisajas MB võrra, sõltuvalt serverist ja mälust.

Protsent mälust, mis on reserveeritud minFree jaoks

Mälupiirang

128 GB 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ärelejäänud mälu (100 GB)

1024 MB

Tavaliselt peetakse produktiivsete serverite jaoks normaalseks ainult kõrge oleku. Testimis- ja arendussüsteemide puhul võivad vastuvõetavad olekud olla Clear/Soft. Kui hostis on vähemalt 64% MinFree vahemälu alles, siis toimuvad sellel põhinevate VM-ide puhul tõenäoliselt jõudlusprobleemid.

Igas olekus rakendatakse teatud mälu taaskasutamise tehnikaid, alates TPS-ist, mis praktiliselt ei mõjuta VM-i jõudlust, kuni Swappinguni. Räägin neist lähemalt.

Läbipaistev lehe jagamine (TPS). TPS on, julgelt öeldes, virtuaalmasinate mälulehtede dedupeerimine serveris.

ESXi otsib sarnaseid virtuaalmasinate mälulehti, arvutades ja võrdledes lehtede hash-summasid ning eemaldab dubleeritud lehed, asendades need viidete tõttu sama lehega füüsilises mälus. Selle tulemusena väheneb füüsilise mälu tarbimine ja on võimalik saavutada teatud mälude ümberkirjutamine praktiliselt ilma jõudluse languseta.

Allikas

Seda mehhanism töötab ainult 4 KB (väikesed lehed) mälulehtede jaoks. 2 MB (suured lehed) lehtede puhul ei ürita hüperviisor deduplikatsiooni isegi teha, kuna sama suurusega lehtede leidmise võimalus on väike.

Vaikimisi eraldab ESXi mälu suurtele lehtedele. Suurte lehtede jagamine väikesteks algab, kui saavutatakse kõrge olek, ja toimub sunniviisiliselt, kui saavutatakse selge olek (vt hüperviisori olekute tabelit).

Kui soovite, et TPS alustaks tööd, ootamata hosti operaatormälu täitumist, peate ESXi Täiustatud valikutes seadma väärtuse “Mem.AllocGuestLargePage” 0-le (vaikimisi 1). Sel juhul keelatakse suurte mälulehtede eraldamine virtuaalmasinatele.

Alates 2014. aasta detsembrist on kõigis ESXi väljaannetes TPS vahel VM-de vahel vaikimisi keelatud, kuna leiti haavatavus, mis teoreetiliselt võimaldab saada ühe VM-i kaudu teise VM-i operaatormälu. Üksikasjad siin. Ma ei ole kohanud teavet TPS haavatavuse praktilise rakendamise kohta.

TPS poliitikat kontrollitakse läbi täiustatud valiku “Mem.ShareForceSalting” ESXi-s:
0 — Inter-VM TPS. TPS töötab erinevate VM-ide lehtede jaoks;
1 – TPS sama 'sched.mem.pshare.salt' väärtusega VM-ide jaoks VMX-is;
2 (vaikimisi) – Intra-VM TPS. TPS töötab lehtede jaoks VM-i sees.

On hädavajalik välja lülitada suured lehed ja aktiveerida Inter-VM TPS testimisjaamades. Seda saab kasutada ka jaamades, kus on palju sarnaseid VM-e. Näiteks VDI jaamades võib füüsilise mälu kokkuhoid ulatuda kümnete protsentideni.

Memory Ballooning. Ballooning ei ole enam nii süütuks ja läbipaistvaks operatsioonisüsteemile VM-i tehnika nagu TPS. Kuid õigesti rakendades on Ballooninguga võimalik elada ja isegi töötada.

Koos Vmware Tools installitakse VM-ile spetsiaalne juhtmega, mida nimetatakse Balloon Driveriks (aka vmmemctl). Kui hüperviisoril hakkab füüsilisest mälust puudu jääma ja ta läheb Soft olekusse, palub ESXi VM-l vabastada mittekasutatav RAM läbi selle Balloon Driveri. Juhtme töötab omakorda operatsioonisüsteemi tasemel ja küsib vabade mälublokkide kohta. Hüperviisor näeb, millised füüsilised mälulehed on Balloon Driveri poolt hõivatud, võtab mälumoodulite virtuaalsest masinast ja tagastab hostile. Probleeme operatsioonisüsteemi tööga ei teki, kuna operatsioonisüsteemi tasandil on mälu hõivatud Balloon Driveri poolt. Vaikimisi saab Balloon Driver võtta kuni 65% VM-i mälust.

Kui VM-il ei ole installitud VMware Tools või on Ballooning välja lülitatud (mida ei soovita, kuid on olemas KB:), siis hüperviisor läheb kohe üle rangematele mälueemaldustehnikatele. Järeldus: veenduge, et VMware Tools oleksid VM-il olemas.

Balloon Driveri tööd saab kontrollida OS-ist läbi VMware Tools.

Memory Compression. Seda meetodit kasutatakse, kui ESXi jõuab Hard olekusse. Nagu nimi viitab, püüab ESXi suruda 4 KB töötlemismälu lehte 2 KB-ks, et vabastada serveri füüsilises mälus natuke ruumi. See tehnika suurendab oluliselt VM-i töötlemismälu lehtede sisu kätte saamise aega, kuna lehte tuleb eelnevalt dekompressida. Mõnikord ei õnnestu kõiki lehti kokku suruda ja kogu protsess võtab aega. Seetõttu ei ole see tehnika praktikas eriti efektiivne.

Mälu vahetamine. Pärast lühikest Mälu kokkusurumise etappi läheb ESXi praktiliselt vältimatult (kui VM-id ei ole teistesse hostidesse liikunud või välja lülitatud) üle vahetamisele. Ja kui mälu on peaaegu otsas (Low olek), lõpetab hüperviisor samuti VM-ide mälu lehtede eraldamise, mis võib põhjustada probleeme VM-i külaliste operatsioonisüsteemides.

Nii töötab vahetus. Kui virtuaalmasin käivitub, luuakse tema jaoks laiendiga .vswp fail. Selle suurus on sama, mis VM-i mittereserveeritud mälu: see on vahe konfigureeritud ja reserveeritud mäluhulga vahel. Vahetuse toimimise ajal laadib ESXi virtuaalmasina mälulehed sellesse faili ja hakkab sellega töötama füüsilise serveri mälu asemel. Loomulikult on selline "mälu" mitu korda aeglasem kui tõeline, isegi kui .vswp asub kiirel salvestusruumil.

Erinevalt Ballooningust, mille puhul VM-ilt võetakse tagasi kasutamata lehed, võivad vahetuse korral kettale minna ka lehed, mida operatsioonisüsteem või rakendused seespool VM-i aktiivselt kasutavad. Selle tulemusena trên jõudlus langeb kuni kokkujooksmiseni. VM töötab formaalselt ja seda on vähemalt võimalik õigesti välja lülitada operatsioonisüsteemist. Kui olete kannatlik 😉

Kui VM-id on vahetusse läinud, on see ebanormaalne olukord, mida oleks parem vältida.

Virtuaalmasina mälu peamised jõudlusmõõdikud

Nüüd oleme peamise teema juures. VM-i mälastaatuse jälgimiseks on järgmised mõõdikud:

Active — näitab mälu mahtu (KB), millele VM pääses juurde eelneva mõõtmise ajal.

Kasutus — sama, mis Active, kuid protsentides VM-i konfigureeritud mälust. Arvutatakse järgmise valemi järgi: active ÷ virtuaalmasina konfigureeritud mälumaht.
Kõrge Usage ja Active ei ole alati näitajaid VM-i jõudlusprobleemide jaoks. Kui VM kasutab mälu agressiivselt (kui vähemalt pääseb sellele juurde), ei tähenda see, et mälu on ebapiisav. Pigem on see põhjus, miks vaadata, mis OS-is toimub.
VM-i jaoks on saadaval standard Alarm mälu kasutamise kohta:

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

Antud — füüsiline mälu (KB) hostis, mis on antud VM-ile. Sisaldab Shared.

Tarbitud (Granted — Shared) — füüsiline mälu (KB), mida VM hostilt tarbib. Ei sisalda Shared.

Kui osa VM-i mälust antakse mitte füüsilisest mälust hostis, vaid vahetust failist või mälu on VM-ilt ära võetud Balloon Driveri kaudu, siis seda mahtu ei arvestata Granted ega Consumed.
Kõrged Granted ja Consumed väärtused on täiesti normaalsed. Operatsioonisüsteem tõmbab järk-järgult mäluruumi hüperviisorilt tagasi ja ei anna seda enam tagasi. Aja jooksul, kui virtuaalne masin aktiivselt töötab, läheneb nende näitajate väärtus konfigureeritud mälu mahule ja jääb sinna.

Null — VM (KB) mälu maht, mis sisaldab nullide väärtusi. Sellist mälu peab hüperviisor vabaks ja see võib olla muudele virtuaalsetele masinatele eraldatud. Pärast seda, kui külghaldus süsteem on midagi nullitud mällu salvestanud, läheb see Consumed seisundisse ja enam tagasi ei naase.

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

Balloon — mälu maht (KB), mis on VM-lt saadud Balloon Driveri abil välja võetud.

Compressed — mälu maht (KB), mida õnnestus kompressida.

Swapped — mälu maht (KB), mis füüsilise mälu puudumisel serveris on diskile üle viidud.
Balloon ja muud mälu tagastamise tehnika näitajad on null.

Nii näeb välja mälu töökindla VM-i näitaja graafik, millel on 150 GB RAM-i.

Alloleval graafikul on VM-il selged probleemid. Graafiku all on näha, et selle VM-i jaoks on kasutatud kõiki kirjeldatud tehnikaid mäluga töötamiseks. Balloon on selle VM-i jaoks palju suurem kui tarbitud. Tegelikult on VM pigem surnud kui elus.

ESXTOP

Nagu ka CPU puhul, kui soovime kiiresti hinnata hosti olukorda ja selle dünaamikat kuni 2 sekundi intervalliga, tasub kasutada ESXTOPi.

Mälu ESXTOP ekraan avatakse klahviga „m“ ja see näeb välja järgmine (valitud väljad B, D, H, J, K, L, O):

Meid huvitavad järgmised parameetrid:

Mem overcommit avg — keskmine mälust ülekoormus hostis 1, 5 ja 15 minuti jooksul. Kui see on üle nulli, on see põhjus vaadata, mis toimub, kuid see ei pruugi alati tähendada probleemide olemasolu.

Rea PMEM/MB ja VMKMEM/MB — teave serveri füüsilise mälu ja VMkernelile доступной mälu kohta. Siit saab näha huvitavat väärtust minfree (MB-des) ja hosti mälu seisundit (meie puhul kõrge).

Reas NUMA/MB numa-sõlmedes (socketites) on võimalik näha operatiivmälu jaotust. Antud näites on jaotus ebaühtlane, mis üldiselt pole kuigi hea.

Järgnevalt on toodud üldine statistika serveri mälurekonstruktsioonitehnoloogiate kohta:

PSHARE/MB — see on TPS statistika;

SWAP/MB — Swap-i kasutamise statistika;

ZIP/MB — mälu lehtede kokkusurumise statistika;

MEMCTL/MB — Balloon Driveri kasutamise statistika.

Erinevate VM-ide puhul võib meid huvitada järgmine teave. Olen VM-i nimesid varjanud, et mitte publikut segadusse ajada:). Kui ESXTOP-i metrika on sarnane vSphere’i loenduriga, toon vastava loenduri.

MEMSZ — VM-ile konfigureeritud mälu maht (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.

GRANT — Granted MB-des.

TCHD — Aktiivsed MB-des.

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

MCTLSZ — Balloon MB-des.

MCTLGT — operatiivmälu maht (MB), mille ESXi soovib VM-ilt Balloon Driveri kaudu välja võtta (Memctl Target).

MCTLMAX — maksimaalne operatiivmälu maht (MB), mille ESXi võib VM-ilt Balloon Driveri kaudu välja võtta.

SWCUR — praegune operatiivmälu maht (MB), mis on VM-ile antud Swap-failist.

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

Samuti saab ESXTOP kaudu vaadata üksikasjalikumat teavet VM-i NUMA-topoloogia kohta. Selleks tuleb valida väljad D,G:

NHN – NUMA sõlmed, kus VM asub. Siit saab kohe tähele panna wide vm-e, mis ei mahuks ühe NUMA sõlme.

NRMEM – mitu megabaiti mälu võtab VM kaugest NUMA sõlmest.

NLMEM – mitu megabaiti mälu võtab VM lokaalsest NUMA sõlmest.

N%L – protsent mälu VM-is kohaliku NUMA sõlmes (kui alla 80% — võivad tekkida jõudlusprobleemid).

Mälu hüperviisori peal

Kui CPU loendurid hüperviisori peal ei ole tavaliselt kuigi huvitavad, siis mälu olukord on vastupidine. Kõrge Memory Usage VM-is ei pruugi alati tähendada jõudlusprobleemi, kuid kõrge Memory Usage hüperviisori peal kutsub esile mälu haldamise tehnikate tööle asumise ja võib tekitada jõudlusprobleeme VM-is. Tuleb jälgida Host Memory Usage häireid ning mitte lubada VM-il Swap'i sattuda.

Unswap

Kui VM satub Swap'i, siis tema jõudlus langeb oluliselt. Ballooningu ja kompressiooni jäljed kaovad kiiresti pärast seda, kui hostis on vabade mälude olemasolu, kuid VM ei kiirusta Swap'ist serveri mällu tagasi tulema.
Enne ESXi 6.0 versiooni oli ainus usaldusväärne ja kiire viis VM-i Swap'ist välja saamiseks taaskäivitamine (täpsemalt konteineri väljalülitamine / sisse lülitamine). Alates ESXi 6.0-st on olemas kuigi mitte päris ametlik, aga töökindel ja efektiivne meetod VM-i Swap'ist välja toomiseks. Ühel konverentsil sain rääkida ühe VMware inseneriga, kes vastutab CPU ajakava eest. Ta kinnitas, et meetod on täiesti töökindel ja ohutu. Meie kogemustes pole sellega ka probleeme olnud.

Käsk VM-i Swap'ist välja toomiseks kirjeldas Duncan Epping. Ei hakka kordama põhjalikku kirjeldust, lihtsalt toon välja näite selle kasutamisest. Nagu ekraanipildil näha, kaob antud käsu täitmise järel mõne aja pärast Swap VM-ist.

Nõuanded mäluhalduseks ESXi-l

Lõpuks jagan mõned nõuanded, mis aitavad teil vältida VM-i jõudlusprobleeme, mis on seotud mäluga:

• Ärge lubage mäluregistrite üleliigset kasutamist tootmisklastrites. Soovitav on alati hoida ~20-30% vaba mälu klastri sees, et DRS-l (ja administraatoril) oleks manööverdusruumi ning VM-id ei läheks migreerimise ajal Swap'i. Ärge unustage ka varu talitlushäirete vältimiseks. Pole meeldiv, kui ühe serveri rikke ajal ja VM-idest HA kaudu ümberlaadimisel mõned masinad veel Swap'i satuvad.
• Kõrge konsolideerimisega infrastruktuurides vältige VM-ide loomist, mille mälu ületab poole hosti mälu. See aitab taas DRS-il probleemideta virtuaalseid masinaid klastri serverite vahel jaotada. See reegel ei ole loomulikult universaalne : ).
• Jälgige Host Memory Usage Alarmi.
• Ärge unustage paigaldada VM-idele VMware Tools ja mitte keelata Ballooning'ut.
• Kaaluge Inter-VM TPS-i lubamist ja Large Pages'i keelamist VDI-keskkondades ja katsetamisvõimalustes.
• Kui VM-il on jõudlusprobleeme, kontrollige, kas see kasutab mälu eemalt NUMA sõlmedelt.
• Väljastage VM Swap'ist võimalikult kiiresti! Kõikide muude asjade seas kannatab STH, kui VM on Swap'is, mis on ilmselge põhjus.

Sellega on minu poolne teema RAM-i kohta lõpetatud. Allpool on artiklid, mis käsitlevad teemat lähemalt neile, kes soovivad üksikasjadesse süveneda. Järgmine artikkel käsitleb salvestamist.

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