Analiza performansi VM-a u VMware vSphere. Dio 2: Memorija

Analiza performansi VM-a u VMware vSphere. Dio 2: Memorija

Dio 1. O CPU-u

U ovom članku ćemo govoriti o brojačima performansi memorije sa slučajnim pristupom (RAM) u vSphere.
Čini se da je s memorijom sve jasnije nego s procesorom: ako se na VM-u pojave problemi s performansama, teško ih je ne primijetiti. Ali ako se pojave, mnogo je teže nositi se s njima. Ali prvo stvari.

Malo teorije

RAM virtuelnih mašina uzima se iz memorije servera na kojem se pokreću VM. Ovo je sasvim očigledno :). Ako RAM servera nije dovoljan za sve, ESXi počinje da koristi tehnike obnavljanja memorije. U suprotnom, VM operativni sistemi bi se srušili sa greškama u pristupu RAM-u.

ESXi odlučuje koje će tehnike koristiti ovisno o RAM-u:

Status memorije

Frontier

Akcije

visok

400% minBesplatno

Nakon dostizanja gornje granice, velike memorijske stranice se dijele na male (TPS radi u standardnom načinu rada).

jasno

100% minBesplatno

Velike memorijske stranice se dijele na male, TPS je prisiljen.

mekan

64% minBesplatno

TPS + balon

tvrd

32% minBesplatno

TPS + Compress + Swap

nizak

16% minBesplatno

Compress + Swap + Block

Izvor

minFree je RAM potrebna za rad hipervizora.

Do uključujući ESXi 4.1, minFree je po defaultu fiksiran - 6% RAM-a servera (procenat se može promijeniti putem opcije Mem.MinFreePct na ESXi). U kasnijim verzijama, zbog rasta memorije na serverima, minFree je počeo da se računa na osnovu količine memorije hosta, a ne kao fiksne procentualne vrijednosti.

MinFree vrijednost (zadano) se izračunava na sljedeći način:

Postotak memorije rezerviran za minFree

Raspon memorije

6%

0-4 GB

4%

4-12 GB

2%

12-28 GB

1%

Preostala memorija

Izvor

Na primjer, za server sa 128 GB RAM-a, MinFree vrijednost će biti sljedeća:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Stvarna vrijednost može se razlikovati za nekoliko stotina MB, ovisno o serveru i RAM-u.

Postotak memorije rezerviran za minFree

Raspon memorije

Vrijednost za 128 GB

6%

0-4 GB

245,76 MB

4%

4-12 GB

327,68 MB

2%

12-28 GB

327,68 MB

1%

Preostala memorija (100 GB)

1024 MB

Uobičajeno, za produktivne sastojine samo se visoko stanje može smatrati normalnim. Za klupe za testiranje i razvoj, Clear/Soft stanja mogu biti prihvatljiva. Ako je RAM na hostu manji od 64% MinFree, tada VM-ovi koji rade na njemu definitivno imaju problema s performansama.

U svakom stanju koriste se određene tehnike obnavljanja memorije, počevši od TPS-a, koji praktično nema utjecaja na performanse VM-a, do zamjene. Reći ću vam više o njima.

Transparentno dijeljenje stranica (TPS). TPS je, grubo rečeno, deduplikacija RAM stranica virtuelnih mašina na serveru.

ESXi traži identične RAM stranice virtuelne mašine brojanjem i upoređivanjem heš sume stranica, i uklanja duple stranice, zamenjujući ih referencama na istu stranicu u fizičkoj memoriji servera. Kao rezultat toga, potrošnja fizičke memorije je smanjena, a određena pretplata memorije se može postići gotovo bez utjecaja na performanse.

Analiza performansi VM-a u VMware vSphere. Dio 2: Memorija
Izvor

Ovaj mehanizam radi samo za memorijske stranice veličine 4 KB (male stranice). Hipervizor čak ni ne pokušava da deduplicira stranice veličine 2 MB (velike stranice): šansa za pronalaženje identičnih stranica ove veličine nije velika.

Podrazumevano, ESXi dodeljuje memoriju velikim stranicama. Podjela velikih stranica na male stranice počinje kada se dostigne prag visokog stanja i prisiljava se kada se dostigne stanje Clear (pogledajte tabelu stanja hipervizora).

Ako želite da TPS počne raditi bez čekanja da se host RAM napuni, potrebno je da postavite vrijednost u Naprednim opcijama ESXi “Mem.AllocGuestLargePage” na 0 (podrazumevano 1). Tada će dodjela velikih memorijskih stranica za virtuelne mašine biti onemogućena.

Od decembra 2014. godine, u svim izdanjima ESXi, TPS između VM-a je podrazumevano onemogućen, pošto je otkrivena ranjivost koja teoretski omogućava jednoj VM da pristupi RAM-u druge VM. Detalji ovdje. Nisam naišao na informacije o praktičnoj implementaciji iskorišćavanja TPS ranjivosti.

TPS politika se kontrolira putem napredne opcije “Mem.ShareForceSalting” na ESXi:
0 - Inter-VM TPS. TPS radi za stranice različitih VM-ova;
1 – TPS za VM sa istom vrednošću “sched.mem.pshare.salt” u VMX-u;
2 (podrazumevano) – Intra-VM TPS. TPS radi za stranice unutar VM-a.

Definitivno ima smisla onemogućiti velike stranice i omogućiti Inter-VM TPS na testnim stolovima. Ovo se također može koristiti za štandove s velikim brojem sličnih VM-ova. Na primjer, na štandovima s VDI, uštede u fizičkoj memoriji mogu doseći desetine posto.

Memory Ballooning. Baloniranje više nije tako bezopasna i transparentna tehnika za VM operativni sistem kao TPS. Ali ako se pravilno koristi, možete živjeti, pa čak i raditi s balonom.

Zajedno sa Vmware Tools, poseban drajver pod nazivom Balloon Driver (aka vmmemctl) je instaliran na VM. Kada hipervizoru počne ponestajati fizičke memorije i uđe u Soft stanje, ESXi traži od VM-a da povrati neiskorištenu RAM memoriju putem ovog balon drajvera. Drajver, zauzvrat, radi na nivou operativnog sistema i od njega zahteva slobodnu memoriju. Hipervizor vidi koje stranice fizičke memorije je Balloon Driver zauzeo, uzima memoriju od virtuelne mašine i vraća je hostu. Nema problema s radom OS-a, jer na nivou OS-a memoriju zauzima Balloon Driver. Po defaultu, Balloon Driver može zauzeti do 65% VM memorije.

Ako VMware alati nisu instalirani na VM ili je baloniranje onemogućeno (ne preporučujem, ali postoji KB:), hipervizor se odmah prebacuje na strože tehnike za uklanjanje memorije. Zaključak: provjerite jesu li VMware alati na VM-u.

Analiza performansi VM-a u VMware vSphere. Dio 2: Memorija
Rad Balloon Driver-a može se provjeriti iz OS-a putem VMware alata.

Kompresija memorije. Ova tehnika se koristi kada ESXi dostigne Hard stanje. Kao što ime sugerira, ESXi pokušava komprimirati stranicu od 4 KB RAM-a u 2 KB, oslobađajući tako nešto prostora u fizičkoj memoriji servera. Ova tehnika značajno povećava vrijeme pristupa sadržaju VM RAM stranica, budući da se stranica prvo mora dekomprimirati. Ponekad se ne mogu sve stranice komprimirati i sam proces traje neko vrijeme. Stoga ova tehnika nije baš efikasna u praksi.

Zamjena memorije. Nakon kratke faze kompresije memorije, ESXi gotovo neizbježno (ako VM nisu premješteni na druge hostove ili nisu isključeni) prelazi na zamjenu. A ako je ostalo vrlo malo memorije (nisko stanje), onda hipervizor takođe prestaje da dodjeljuje memorijske stranice VM-u, što može uzrokovati probleme u gostujućem OS-u VM-a.

Ovako funkcionira Zamjena. Kada uključite virtuelnu mašinu, za nju se kreira datoteka sa ekstenzijom .vswp. Po veličini je jednaka nerezerviranoj RAM-u VM-a: ovo je razlika između konfigurirane i rezervirane memorije. Kada je Zamjena pokrenuta, ESXi zamjenjuje stranice memorije virtuelne mašine u ovu datoteku i počinje da radi sa njom umesto sa fizičkom memorijom servera. Naravno, takva “RAM” memorija je nekoliko redova veličine sporija od stvarne memorije, čak i ako je .vswp na brzoj memoriji.

Za razliku od baloniranja, kada se neiskorištene stranice preuzmu iz VM-a, sa zamjenom stranica koje aktivno koristi OS ili aplikacije unutar VM-a mogu se premjestiti na disk. Kao rezultat toga, performanse VM-a opadaju do tačke zamrzavanja. VM formalno radi i u najmanju ruku može se ispravno onemogućiti iz OS-a. Ako ste strpljivi 😉

Ako su VM-ovi otišli u Swap, ovo je hitna situacija koju je najbolje izbjeći ako je moguće.

Osnovni brojači performansi memorije virtuelne mašine

Dakle, došli smo do glavne stvari. Za praćenje stanja memorije VM-a postoje sljedeći brojači:

aktivnih — pokazuje količinu RAM-a (KB) kojoj je VM pristupio u prethodnom periodu mjerenja.

upotreba — isto kao Active, ali kao procenat konfigurisanog RAM-a VM-a. Izračunava se pomoću sljedeće formule: aktivna ÷ veličina memorije konfigurirane virtualne mašine.
Visoka upotreba i Aktivno, respektivno, nisu uvijek indikator problema s performansama VM-a. Ako VM agresivno koristi memoriju (barem joj pristupa), to ne znači da nema dovoljno memorije. Umjesto toga, ovo je razlog da se pogleda šta se dešava u OS-u.
Postoji standardni alarm za korištenje memorije za VM:

Analiza performansi VM-a u VMware vSphere. Dio 2: Memorija

Zajednička — količina VM RAM-a dedupliciranog pomoću TPS-a (unutar VM-a ili između VM-a).

Granted — količina fizičke memorije hosta (KB) koja je dodijeljena VM-u. Omogućuje Shared.

Konzumira (Odobreno - dijeljeno) - količina fizičke memorije (KB) koju VM troši od hosta. Ne uključuje Shared.

Ako se dio VM memorije ne daje iz fizičke memorije hosta, već iz zamjenske datoteke, ili se memorija uzima iz VM-a preko Balloon Driver-a, ovaj iznos se ne uzima u obzir u Odobreno i Potrošeno.
Visoke odobrene i potrošene vrijednosti su potpuno normalne. Operativni sistem postepeno uzima memoriju od hipervizora i ne vraća je. S vremenom, u aktivno pokrenutom VM-u, vrijednosti ovih brojača se približavaju količini konfigurirane memorije i tamo ostaju.

nula — količina VM RAM-a (KB), koja sadrži nule. Takvu memoriju hipervizor smatra slobodnom i može se dati drugim virtuelnim mašinama. Nakon što je gostujući OS nešto napisao u nuliranoj memoriji, ono ide u Consumed i ne vraća se nazad.

Rezervisano iznad glave — količina VM RAM-a, (KB) rezervisana od strane hipervizora za rad VM. Ovo je mala količina, ali mora biti dostupna na hostu, inače se VM neće pokrenuti.

balon — količina RAM-a (KB) uklonjene iz VM-a pomoću Balloon Driver-a.

Komprimovani — količina RAM-a (KB) koja je komprimirana.

Zamenjen — količina RAM-a (KB) koja je, zbog nedostatka fizičke memorije na serveru, premještena na disk.
Brojači balona i drugih tehnika obnavljanja memorije su nula.

Ovako izgleda grafikon sa brojačima memorije normalnog VM-a sa 150 GB RAM-a.

Analiza performansi VM-a u VMware vSphere. Dio 2: Memorija

Na grafikonu ispod, VM ima očigledne probleme. Ispod grafikona možete vidjeti da su za ovaj VM korištene sve opisane tehnike rada sa RAM-om. Balon za ovaj VM je mnogo veći od Consumed. U stvari, VM je više mrtav nego živ.

Analiza performansi VM-a u VMware vSphere. Dio 2: Memorija

ESXTOP

Kao i kod CPU-a, ako želimo brzo procijeniti situaciju na hostu, kao i njegovu dinamiku u intervalu do 2 sekunde, trebali bismo koristiti ESXTOP.

Ekran ESXTOP memorije se poziva tipkom “m” i izgleda ovako (odabrana polja B,D,H,J,K,L,O):

Analiza performansi VM-a u VMware vSphere. Dio 2: Memorija

Sljedeći parametri će nas zanimati:

Mem overcommit prosj — prosječna vrijednost prekoračenja memorije na hostu za 1, 5 i 15 minuta. Ako je iznad nule, onda je to razlog da se pogleda šta se dešava, ali ne i uvek pokazatelj problema.

U redovima PMEM/MB и VMKMEM/MB — informacije o fizičkoj memoriji servera i memoriji dostupnoj VMkernelu. Među zanimljivostima ovdje možete vidjeti vrijednost minfree (u MB), stanje hosta u memoriji (u našem slučaju visoko).

U redu NUMA/MB možete vidjeti distribuciju RAM-a po NUMA čvorovima (utičnicama). U ovom primjeru distribucija je neravnomjerna, što u principu nije dobro.

Slijedi opća statistika servera za tehnike obnavljanja memorije:

PSHARE/MB — ovo je TPS statistika;

SWAP/MB — Statistika korištenja zamjene;

ZIP/MB — statistiku kompresije memorijske stranice;

MEMCTL/MB — Statistika upotrebe Balon Driver.

Za pojedinačne VM-ove, možda će nas zanimati sljedeće informacije. Sakrio sam imena VM-a da ne zbunim publiku :). Ako je ESXTOP metrika slična brojaču u vSphere, dat ću odgovarajući brojač.

MEMSZ — količina memorije konfigurisane na VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + netaknut.

GRANT — Odobreno u MB.

TCHD — Aktivan u MByte.

MCTL? — da li je Balloon Driver instaliran na VM.

MCTLSZ — Balon za MB.

MCTLGT — količina RAM-a (MBytes) koju ESXi želi ukloniti iz VM-a preko Balloon Driver-a (Memctl Target).

MCTLMAX — maksimalna količina RAM-a (MBytes) koju ESXi može ukloniti iz VM-a preko Balloon Driver-a.

SWCUR — trenutna količina RAM-a (MBytes) dodijeljena VM-u iz Swap datoteke.

S.W.G.T. — količina RAM-a (MBytes) koju ESXi želi dati VM-u iz Swap datoteke (Swap Target).

Također možete vidjeti detaljnije informacije o NUMA topologiji VM-a kroz ESXTOP. Da biste to učinili, odaberite polja D, G:

Analiza performansi VM-a u VMware vSphere. Dio 2: Memorija

SMALL – NUMA čvorovi na kojima se nalazi VM. Ovdje možete odmah primijetiti široki vm, koji ne stanu na jedan NUMA čvor.

NRMEM – koliko megabajta memorije VM uzima od udaljenog NUMA čvora.

NLMEM – koliko megabajta memorije VM uzima od lokalnog NUMA čvora.

N%L – postotak VM memorije na lokalnom NUMA čvoru (ako je manji od 80%, mogu se pojaviti problemi s performansama).

Memorija na hipervizoru

Ako CPU brojači za hipervizor obično nisu od posebnog interesa, onda je s memorijom situacija suprotna. Visoka upotreba memorije na VM-u ne ukazuje uvijek na problem s performansama, ali velika upotreba memorije na hipervizoru pokreće tehnike upravljanja memorijom i uzrokuje probleme s performansama VM-a. Morate pratiti alarme o korištenju memorije hosta i spriječiti da VM uđu u Swap.

Analiza performansi VM-a u VMware vSphere. Dio 2: Memorija

Analiza performansi VM-a u VMware vSphere. Dio 2: Memorija

Unswap

Ako je VM uhvaćen u Swap-u, njegove performanse su znatno smanjene. Tragovi baloniranja i kompresije brzo nestaju nakon što se slobodna RAM memorija pojavi na hostu, ali virtuelna mašina ne žuri da se vrati iz Swap-a u RAM servera.
Prije ESXi 6.0, jedini pouzdan i brz način uklanjanja VM-a iz Swap-a bio je ponovno pokretanje (tačnije, isključivanje/uključivanje kontejnera). Počevši od ESXi 6.0, iako ne sasvim zvaničan, pojavio se funkcionalan i pouzdan način za uklanjanje VM-a iz Swap-a. Na jednoj od konferencija, mogao sam da razgovaram sa jednim od VMware inženjera odgovornim za CPU Scheduler. Potvrdio je da je metoda prilično djelotvorna i sigurna. Prema našem iskustvu, ni s tim nije bilo problema.

Stvarne naredbe za uklanjanje VM-a iz Swap-a opisano Duncan Epping. Neću ponavljati detaljan opis, samo ću navesti primjer njegove upotrebe. Kao što možete vidjeti na snimku ekrana, nakon nekog vremena nakon izvršenja navedene naredbe, Swap na VM-u nestaje.

Analiza performansi VM-a u VMware vSphere. Dio 2: Memorija

Savjeti za upravljanje RAM-om na ESXi

Na kraju, evo nekoliko savjeta koji će vam pomoći da izbjegnete probleme s performansama VM-a zbog RAM-a:

  • Izbjegavajte prekomjernu pretplatu RAM-a u produktivnim klasterima. Preporučljivo je uvijek imati ~20-30% slobodne memorije u klasteru kako bi DRS (i administrator) imali prostora za manevrisanje i VM-ovi ne bi otišli u Swap tokom migracije. Također, ne zaboravite na marginu za toleranciju grešaka. Neprijatno je kada, kada jedan server pokvari i VM se ponovo pokrene pomoću HA, neke mašine takođe odu u Swap.
  • U visoko konsolidovanim infrastrukturama, pokušajte NE kreirati VM-ove sa memorijom većom od polovine memorije hosta. Ovo će opet pomoći DRS-u da distribuira virtuelne mašine preko servera klastera bez ikakvih problema. Ovo pravilo, naravno, nije univerzalno :).
  • Pazite na alarm za korištenje memorije domaćina.
  • Ne zaboravite instalirati VMware Tools na VM i nemojte isključivati ​​baloniranje.
  • Razmislite o omogućavanju Inter-VM TPS-a i onemogućavanju velikih stranica u VDI i testnim okruženjima.
  • Ako VM ima problema s performansama, provjerite da li koristi memoriju iz udaljenog NUMA čvora.
  • Uklonite VM-ove iz Swap-a što je prije moguće! Između ostalog, ako je VM u Swap-u, sistem skladištenja pati iz očiglednih razloga.

To je sve za mene o RAM-u. Ispod su povezani članci za one koji žele ići dublje. Sljedeći članak će biti posvećen storaj.

korisni linkovihttp://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

izvor: www.habr.com

Dodajte komentar