{"id":35292,"date":"2019-10-31T22:03:28","date_gmt":"2019-10-31T19:03:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory\/"},"modified":"2019-10-31T22:03:28","modified_gmt":"2019-10-31T19:03:28","slug":"analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"Analiza performansi VM u VMware vSphere. Dio 2: Memorija","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Analiza
\n
\nDio 1. O CPU-u<\/a><\/noindex><\/p>\n

U ovom \u010dlanku govorimo o pokazateljima performansi radne memorije (RAM) u vSphere.
\n\u010cini se da je s memorijom sve jasnije nego s procesorom: ako na VM-ovima do\u0111e do problema s performansama, te\u0161ko ih je ne primijetiti. No, kada se pojave, mnogo je te\u017ee rije\u0161iti ih. Ali idemo redom. <\/a><\/noindex><\/p>\n

Malo teorije<\/h3>\n

\nRadna memorija virtualnih ma\u0161ina dolazi iz memorije poslu\u017eitelja na kojem su VM-ovi pokrenuti. To je sasvim o\u010dito :). Ako radne memorije poslu\u017eitelja nije dovoljno za sve koji je zahtijevaju, ESXi po\u010dinje primjenjivati tehnike optimizacije potro\u0161nje radne memorije (tehnike povrata memorije). Ina\u010de bi operativni sustavi VM-a padali s gre\u0161kama pristupa RAM-u. <\/p>\n

Koje tehnike primijeniti ESXi odlu\u010duje na temelju optere\u0107enja radne memorije:<\/p>\n

Stanje memorije<\/b><\/p>\n

Granica<\/b><\/p>\n

Radnje<\/b><\/p>\n

Visoko<\/p>\n

400% od minFree<\/p>\n

Nakon dostizanja gornje granice, velike stranice memorije se razbijaju na male (TPS radi u standardnom na\u010dinu rada).<\/p>\n

O\u010distiti<\/p>\n

100% od minFree<\/p>\n

Velike stranice memorije se razbijaju na male, TPS radi prisilno.<\/p>\n

Soft<\/p>\n

64% od minFree<\/p>\n

TPS + Balloon<\/p>\n

Hard<\/p>\n

32% od minFree<\/p>\n

TPS + Compress + Swap<\/p>\n

Nisko<\/p>\n

16% od minFree<\/p>\n

Compress + Swap + Block<\/p>\n

Izvor<\/a><\/noindex> <\/p>\n

minFree je radna memorija potrebna za rad hipervizora. <\/p>\n

Do ESXi 4.1 uklju\u010divo minFree je po zadanom bio fiksiran \u2014 6% od volumena radne memorije poslu\u017eitelja (postotak se mogao promijeniti putem opcije Mem.MinFreePct na ESXi). U novijim verzijama zbog rasta volumena memorije na poslu\u017eiteljima, minFree se po\u010delo izra\u010dunavati na temelju volumena memorije doma\u0107ina, a ne kao fiksna postotna vrijednost. <\/p>\n

Vrijednost minFree (po zadanom) izra\u010dunava se na sljede\u0107i na\u010din:<\/p>\n

Postotak memorije rezervirane za minFree<\/b><\/p>\n

Raspon memorije<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

1%<\/p>\n

Preostala memorija<\/p>\n

Izvor<\/a><\/noindex><\/p>\n

Na primjer, za poslu\u017eitelj s 128 GB RAM-a, vrijednost MinFree bit \u0107e ovakva:
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
\nStvarna vrijednost mo\u017ee se razlikovati za nekoliko stotina MB, ovisno o poslu\u017eitelju i radnoj memoriji.<\/p>\n

Postotak memorije rezervirane za minFree<\/b><\/p>\n

Raspon memorije<\/b><\/p>\n

Vrijednost za 128 GB<\/b><\/p>\n

6%<\/p>\n

0-4 GB<\/p>\n

245,76 MB<\/p>\n

4%<\/p>\n

4-12 GB<\/p>\n

327,68 MB<\/p>\n

2%<\/p>\n

12-28 GB<\/p>\n

327,68 MB<\/p>\n

1%<\/p>\n

Preostala memorija (100 GB)<\/p>\n

1024 MB<\/p>\n

\nObi\u010dno se za produkcijske postavke samo stanje High mo\u017ee smatrati normalnim. Za postavke za testiranje i razvoj, prihvatljiva mogu biti stanja Clear\/Soft. Ako je na hostu ostalo manje od 64% MinFree, tada \u0107e VM-ovi koji na njemu rade sigurno pokazivati probleme s performansama.<\/p>\n

U svakom stanju primjenjuju se odre\u0111ene tehnike vra\u0107anja memorije, po\u010dev\u0161i od TPS-a, koji prakti\u010dki ne utje\u010de na performanse VM-a, do swappinga. O njima \u0107u govoriti detaljnije. <\/p>\n

Transparent Page Sharing (TPS).<\/b> TPS je, pojednostavljeno, dedupliciranje stranica radne memorije virtualnih ma\u0161ina na serveru.<\/p>\n

ESXi tra\u017ei identi\u010dne stranice radne memorije virtualnih ma\u0161ina uspore\u0111uju\u0107i i porede\u0107i hash vrijednosti stranica, a zatim uklanja duplikate stranica zamjenjuju\u0107i ih referencama na istu stranicu u fizi\u010dkoj memoriji servera. Kao rezultat, potro\u0161nja fizi\u010dke memorije se smanjuje i mo\u017ee se posti\u0107i odre\u0111ena prezahtijevanja memorije prakti\u010dki bez smanjenja performansi.<\/p>\n

\"Analiza
\nIzvor<\/a><\/noindex><\/p>\n

Ovaj mehanizam radi samo za stranice memorije veli\u010dine 4 KB (male stranice). Hipervizor ne poku\u0161ava deduplicirati stranice veli\u010dine 2 MB (velike stranice) jer je vjerojatnost pronalaska identi\u010dnih stranica te veli\u010dine mala.<\/p>\n

Prema zadanim postavkama, ESXi dodjeljuje memoriju velikim stranicama. Razdvajanje velikih stranica na male po\u010dinje kada se dostigne prag stanja High i doga\u0111a se prisilno kada se dostigne stanje Clear (vidi tablicu stanja hipervizora).<\/p>\n

Ako \u017eelite da TPS po\u010dne raditi bez \u010dekanja na ispunjenje radne memorije hosta, trebate postaviti vrijednost \u201cMem.AllocGuestLargePage\u201d<\/i> na 0 (prema zadanim postavkama 1). Tada \u0107e dodjeljivanje velikih stranica memorije za virtualne ma\u0161ine biti onemogu\u0107eno.<\/p>\n

Od prosinca 2014. u svim izdanjima ESXi, TPS izme\u0111u VM-a je prema zadanim postavkama isklju\u010den, jer je prona\u0111ena ranjivost koja teoretski omogu\u0107ava pristup radnoj memoriji jedne VM kroz drugu VM. Detalji ovdje. Informacije o prakti\u010dnoj realizaciji iskori\u0161tavanja ranjivosti TPS nisam nalazio.<\/p>\n

Politika TPS kontrolira se preko napredne opcije \u201cMem.ShareForceSalting\u201d<\/i> na ESXi:
\n0 \u2014 Inter-VM TPS. TPS radi za stranice razli\u010ditih VM-a;
\n1 \u2013 TPS za VM s istom vrijedno\u0161\u0107u \u201csched.mem.pshare.salt\u201d u VMX-u;
\n2 (prema zadanim postavkama) \u2013 Intra-VM TPS. TPS radi za stranice unutar VM-a.<\/p>\n

Definitivno ima smisla isklju\u010diti velike stranice i uklju\u010diti Inter-VM TPS na testnim okru\u017eenjima. Tako\u0111er se mo\u017ee koristiti za okru\u017eenja s velikim brojem sli\u010dnih VM-a. Na primjer, na okru\u017eenjima s VDI, u\u0161teda fizi\u010dke memorije mo\u017ee dose\u0107i desetke posto. <\/p>\n

Memory Ballooning.<\/b> Ballooning vi\u0161e nije toliko bezopasan i proziran tehnika za operacijski sustav VM kao TPS. Me\u0111utim, uz pravilnu primjenu, Ballooning mo\u017ee biti funkcionalan i \u010dak koristan.<\/p>\n

Uz VMware Tools na VM-u instalira se posebni upravlja\u010dki program poznat kao Balloon Driver (tako\u0111er vmmemctl). Kada hipervizoru ponestane fizi\u010dke memorije i pre\u0111e u stanje Soft, ESXi tra\u017ei od VM-a da vrati neiskori\u0161tenu RAM putem ovog Balloon Drivera. Upravlja\u010dki program, s druge strane, radi na razini operacijskog sustava i tra\u017ei slobodnu memoriju od njega. Hipervizor vidi koje stranice fizi\u010dke memorije je zauzeo Balloon Driver, uzima memoriju od virtualne ma\u0161ine i vra\u0107a je hostu. Problemi s radom OS-a se ne javljaju, jer je na razini OS-a memorija zauzeta od strane Balloon Drivera. Prema zadanim postavkama, Balloon Driver mo\u017ee uzeti do 65% memorije VM-a.<\/p>\n

Ako na VM-u nisu instalirani VMware Tools ili je Ballooning isklju\u010den (ne preporu\u010dujem, ali postoji KB<\/a><\/noindex>:), hipervizor odmah prelazi na rigorozniju tehniku uzimanja memorije. Zaklju\u010dak: pazite da VMware Tools budu prisutni na VM-u.<\/p>\n

\"Analiza
\nRad Balloon Drivera mo\u017ee se provjeriti iz OS-a putem VMware Tools<\/i>.<\/p>\n

Memory Compression.<\/b> Ova tehnika se primjenjuje kada ESXi do\u0111e do stanja Hard. Kao \u0161to naziv sugerira, ESXi poku\u0161ava komprimirati 4 KB stranice RAM-a na 2 KB, \u010dime se osloba\u0111a malo prostora u fizi\u010dkoj memoriji servera. Ova tehnika zna\u010dajno pove\u0107ava vrijeme pristupa sadr\u017eaju stranica RAM-a VM-a, jer je potrebno prvo dekomprimirati stranicu. Ponekad nije mogu\u0107e komprimirati sve stranice, a sam proces traje odre\u0111eno vrijeme. Stoga ova tehnika u praksi nije vrlo u\u010dinkovita.<\/p>\n

Memory Swapping.<\/b> Nakon kratke faze Memory Compression, ESXi prakti\u010dki neizbje\u017eno (osim ako VM-i nisu preba\u010deni na druge hostove ili isklju\u010deni) prelazi na Swapping. A ako ostane vrlo malo memorije (stanje Low), hipervizor tako\u0111er prestaje dodjeljivati VM-ima stranice memorije, \u0161to mo\u017ee izazvati probleme u gostuju\u0107im OS-ima VM-a.<\/p>\n

Evo kako radi Swapping. Kada se uklju\u010duje virtualna ma\u0161ina, za nju se kreira datoteka s ekstenzijom .vswp. Po veli\u010dini je jednaka nerezerviranoj radnoj memoriji VM-a: to je razlika izme\u0111u konfigurirane i rezervirane memorije. Kada je Swapping aktivan, ESXi premje\u0161ta stranice memorije virtualne ma\u0161ine u ovu datoteku i po\u010dinje raditi s njom umjesto s fizi\u010dkom memorijom poslu\u017eitelja. Naravno, takva \u201eradna\u201c memorija je nekoliko puta sporija od prave, \u010dak i ako se .vswp nalazi na brzom pohranu.<\/p>\n

Za razliku od Ballooninga, kada VM oduzima neiskori\u0161tene stranice, prilikom Swappinga na disk mogu pre\u0107i stranice koje aktivno koristi OS ili aplikacije unutar VM-a. Kao rezultat, performanse VM-a naglo opadaju, \u010dak do zastoja. VM formalno radi i mo\u017ee se ispravno isklju\u010diti iz OS-a. Ako budete strpljivi \ud83d\ude09<\/p>\n

Ako su VM-ovi pre\u0161li u Swap \u2014 to je nepravilna situacija koju je najbolje izbje\u0107i kada god je to mogu\u0107e.<\/p>\n

Glavni pokazatelji performansi memorije virtualne ma\u0161ine<\/h3>\n

\nEvo, stigli smo do glavnog. Za pra\u0107enje statusa memorije u VM-u postoje sljede\u0107i pokazatelji:<\/p>\n

Aktivno<\/b> \u2014 pokazuje koli\u010dinu radne memorije (KB) kojoj je VM imala pristup u prethodnom mjerodavnom razdoblju.<\/p>\n

Kori\u0161tenje<\/b> \u2014 isto kao Aktivno, ali u postocima od konfigurirane radne memorije VM-a. Izra\u010dunava se prema sljede\u0107oj formuli: active \u00f7 virtual machine configured memory size.
\nVisok Usage i Aktivno, prema tome, ne ukazuju uvijek na probleme s performansama VM-a. Ako VM agresivno koristi memoriju (barem, ima pristup), to ne zna\u010di da joj nedostaje memorije. Radije je to prilika da provjerite \u0161to se doga\u0111a unutar OS-a.
\nPostoji standardni Alarm za Kori\u0161tenje Memorije za VM:<\/p>\n

\"Analiza
\n
\nDijeljeni<\/b> \u2014 koli\u010dina radne memorije VM-a, deduplirane pomo\u0107u TPS (unutar VM-a ili izme\u0111u VM-ova).<\/p>\n

Odobreno<\/b> \u2014 koli\u010dina fizi\u010dke memorije poslu\u017eitelja (KB), koja je dodijeljena VM-u. Uklju\u010duje Shared.<\/p>\n

Potro\u0161eno<\/b> (Odobreno \u2014 Shared) \u2014 koli\u010dina fizi\u010dke memorije (KB) koju VM tro\u0161i s poslu\u017eitelja. Ne uklju\u010duje Shared.<\/p>\n

Ako dio memorije VM-a dolazi ne iz fizi\u010dke memorije poslu\u017eitelja, ve\u0107 iz swap datoteke ili je memorija oduzeta od VM-a putem Balloon Driver-a, ta koli\u010dina se ne uzima u obzir u Odobreno i Potro\u0161eno.
\nVisoke vrijednosti Granted i Consumed su potpuno normalne. Operativni sustav postupno uzima memoriju od hipervizora i ne vra\u0107a je natrag. S vremenom, kod aktivne VM, vrijednosti ovih brojila se pribli\u017eavaju volumenu konfigurirane memorije i tamo ostaju.<\/p>\n

Nula<\/b> \u2014 volumen radne memorije VM (KB), koji sadr\u017ei nule. Ova memorija se smatra slobodnom od strane hipervizora i mo\u017ee se dodijeliti drugim virtualnim strojevima. Nakon \u0161to operativni sustav gosta zapi\u0161e ne\u0161to u nulti memoriju, prelazi u Consumed i vi\u0161e se ne vra\u0107a.<\/p>\n

Reserved Overhead<\/b> \u2014 volumen radne memorije VM (KB) rezerviran od strane hipervizora za rad VM. To je mali volumen, ali mora biti prisutan na hostu, ina\u010de VM ne\u0107e krenuti.<\/p>\n

Balloon<\/b> \u2014 volumen radne memorije (KB), koji je oduzet od VM putem Balloon Drivera.<\/p>\n

Compressed<\/b> \u2014 volumen radne memorije (KB) koji je uspjelo komprimirati.<\/p>\n

Swapped<\/b> \u2014 volumen radne memorije (KB) koja je, zbog nedostatka fizi\u010dke memorije na serveru, pre\u0161la na disk.
\nBalloon i ostali brojitelji tehnika povrata memorije su jednaki nuli.<\/p>\n

Ovako izgleda grafikon s brojiteljima normalno rade\u0107e VM s 150 GB radne memorije.<\/p>\n

\"Analiza
\n
\nNa grafu ispod, VM ima jasne probleme. Ispod grafa, vidi se da su za ovu VM kori\u0161tene sve opisane tehnike rada s radnom memorijom. Balloon za ovu VM je puno ve\u0107i od Consumed. U praksi, VM je vi\u0161e mrtva nego \u017eiva. <\/p>\n

\"Analiza
\n<\/p>\n

ESXTOP<\/h3>\n

\nKao i s CPU-om, ako \u017eelimo brzo procijeniti situaciju na hostu, kao i njenu dinamiku u intervalu do 2 sekunde, vrijedi koristiti ESXTOP.<\/p>\n

Ekran ESXTOP za Memoriju poziva se tipkom \u201em\u201c i izgleda ovako (odabrana polja B,D,H,J,K,L,O):<\/p>\n

\"Analiza
\n
\nInteresantni za nas bit \u0107e sljede\u0107i parametri: <\/p>\n

Mem overcommit avg<\/b> \u2014 prosje\u010dna vrijednost prekomjerno dodijeljene memorije na hostu tijekom 1, 5 i 15 minuta. Ako je iznad nule, to je razlog da provjerimo \u0161to se doga\u0111a, no to ne mora uvijek zna\u010diti prisutnost problema.<\/p>\n

U redovima PMEM\/MB<\/b> i VMKMEM\/MB<\/b> \u2014 informacije o fizi\u010dkoj memoriji servera i memoriji dostupnoj VMkernelu. Od zanimljivosti ovdje mo\u017eemo vidjeti vrijednost minfree (u MB), stanje hosta prema memoriji (u na\u0161em slu\u010daju, visoko).<\/p>\n

U retku NUMA\/MB<\/b> mo\u017eemo vidjeti raspodjelu radne memorije po NUMA \u010dvorovima (socketima). U ovom primjeru, raspodjela nije ravnomjerna, \u0161to u na\u010delu nije dobro.<\/p>\n

Dalje se nalazi op\u0107a statistika poslu\u017eitelja o tehnikama povrata memorije:<\/p>\n

PSHARE\/MB<\/b> \u2014 to je statistika TPS;<\/p>\n

SWAP\/MB<\/b> \u2014 statistika kori\u0161tenja Swap-a;<\/p>\n

ZIP\/MB<\/b> \u2014 statistika kompresije memorijske stranice;<\/p>\n

MEMCTL\/MB<\/b> \u2014 statistika kori\u0161tenja Balloon Driver-a.<\/p>\n

Mo\u017ee nas zanimati sljede\u0107a informacija o pojedina\u010dnim VM-ovima. Imena VM-ova sam sakrio kako ne bih zbunio publiku :). Ako je ESXTOP metriku mogu\u0107e usporediti s broja\u010dem u vSphere, navodim odgovaraju\u0107i broja\u010d. <\/p>\n

MEMSZ<\/b> \u2014 koli\u010dina memorije konfigurirane na VM-u (MB).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

GRANT<\/b> \u2014 Granted u megabajtima.<\/p>\n

TCHD<\/b> \u2014 Active u megabajtima.<\/p>\n

MCTL?<\/b> \u2014 je li Balloon Driver postavljen na VM-u.<\/p>\n

MCTLSZ<\/b> \u2014 Balloon u megabajtima.<\/p>\n

MCTLGT<\/b> \u2014 koli\u010dina RAM-a (MB) koju ESXi \u017eeli uzeti od VM-a putem Balloon Driver-a (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 maksimalna koli\u010dina RAM-a (MB) koju ESXi mo\u017ee uzeti od VM-a putem Balloon Driver-a.<\/p>\n

SWCUR<\/b> \u2014 trenutna koli\u010dina RAM-a (MB) dodijeljena VM-u iz Swap datoteke. <\/p>\n

SWGT<\/b> \u2014 koli\u010dina RAM-a (MB) koju ESXi \u017eeli dodijeliti VM-u iz Swap datoteke (Swap Target).<\/p>\n

Tako\u0111er putem ESXTOP-a mo\u017ee se pogledati detaljnije informacije o NUMA topologiji VM-a. Za to je potrebno odabrati polja D,G:<\/p>\n

\"Analiza
\n
\nNHN<\/b> \u2013 NUMA \u010dvorovi na kojima se nalaze VM-ovi. Ovdje se odmah mo\u017ee primijetiti wide VM, koji ne staje na jedan NUMA \u010dvor.<\/p>\n

NRMEM<\/b> \u2013 koliko megabajta memorije VM uzima s udaljenog NUMA \u010dvora.<\/p>\n

NLMEM<\/b> \u2013 koliko megabajta memorije VM uzima s lokalnog NUMA \u010dvora.<\/p>\n

N%L<\/b> \u2013 postotak memorije VM na lokalnom NUMA \u010dvoru (ako je manje od 80% \u2014 mogu nastati problemi s performansama).<\/p>\n

Memorija na hipervizoru<\/h3>\n

\nAko broja\u010di CPU-a na hipervizoru obi\u010dno ne predstavljaju posebnu zanimljivost, situacija s memorijom je obrnuta. Visoka upotreba memorije na VM-u ne govori uvijek o prisutnosti problema s performansama, ali visoka upotreba memorije na hipervizoru pokre\u0107e tehnike upravljanja memorijom i uzrokuje probleme s performansama VM-a. Treba pratiti alarme Host Memory Usage i ne dopustiti da VM pre\u0111e u Swap.<\/p>\n

\"Analiza
\n
\n\"Analiza
\n<\/p>\n

Unswap<\/h3>\n

\nAko VM zavr\u0161i u Swapu, njezina se performansa drasti\u010dno smanjuje. Tragovi Ballooning-a i kompresije brzo nestaju nakon \u0161to se na hostu pojavi slobodna RAM, ali vra\u0107anje iz Swapa u RAM poslu\u017eitelja VM-u ne ide lako.
\nDo verzije ESXi 6.0 jedini pouzdani i brzi na\u010din za izbacivanje VM iz Swap-a bilo je ponovno pokretanje (preciznije, isklju\u010divanje\/uklju\u010divanje kontejnera). Po\u010dev\u0161i od ESXi 6.0 pojavio se, iako ne sasvim slu\u017ebeni, ali funkcionalan i pouzdan na\u010din za izbacivanje VM iz Swap-a. Na jednoj od konferencija sam imao priliku razgovarati s jednim od in\u017eenjera VMware-a zadu\u017eenim za CPU Scheduler. Potvrdio je da je taj na\u010din sasvim funkcionalan i siguran. U na\u0161em iskustvu nismo primijetili nikakve probleme s njim.<\/p>\n

Ukratko, komande za izbacivanje VM iz Swap-a opisao<\/a><\/noindex> Duncan Epping. Ne\u0107u ponavljati detaljan opis, samo \u0107u dati primjer njenog kori\u0161tenja. Kao \u0161to se mo\u017ee vidjeti na zaslonu, nakon odre\u0111enog vremena nakon izvr\u0161avanja navedene komande, Swap na VM nestaje.<\/p>\n

\"Analiza
\n<\/p>\n

Savjeti za upravljanje RAM-om na ESXi<\/h3>\n

\nNa kraju \u0107u navesti nekoliko savjeta koji \u0107e vam pomo\u0107i da izbjegnete probleme s performansama VM zbog RAM-a:<\/p>\n