{"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\/sl\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"Analiza performansi VM u VMware vSphere. Deo 2: Memorija","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Analiza
\n
\nCz\u0119\u015b\u0107 1. O CPU<\/a><\/noindex><\/p>\n

V tem \u010dlanku bomo govorili o merilnikih zmogljivosti pomnilnika (RAM) v vSphere.
\nZdi se, da je s pomnilnikom vse bolj enozna\u010dno kot s procesorjem: \u010de na VM pride do te\u017eav z zmogljivostjo, jih je te\u017eko spregledati. \u010ce se te\u017eave pojavijo, se jih je veliko te\u017eje re\u0161iti. A gremo po vrsti. <\/a><\/noindex><\/p>\n

Nekaj teorije<\/h3>\n

\nPomnilnik virtualnih strojev se jemlje iz pomnilnika stre\u017enika, na katerem delujejo VM-ji. To je povsem o\u010ditno :). \u010ce pomnilnika na stre\u017eniku ne zado\u0161\u010da za vse potrebne, ESXi za\u010dne uporabljati tehnike optimizacije porabe pomnilnika (tehnike pridobivanja pomnilnika). V nasprotnem primeru bi se operacijski sistemi VM zru\u0161ili z napakami dostopa do RAM-a. <\/p>\n

Katere tehnike bo ESXi uporabil, se odlo\u010da glede na obremenitev pomnilnika:<\/p>\n

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

Meja<\/b><\/p>\n

Akcije<\/b><\/p>\n

Visoko<\/p>\n

400 % od minFree<\/p>\n

Ko je dose\u017eena zgornja meja, se velike strani pomnilnika razbijejo na manj\u0161e (TPS deluje v standardnem na\u010dinu).<\/p>\n

Po\u010disti<\/p>\n

100 % od minFree<\/p>\n

Velike strani pomnilnika se razbijejo na manj\u0161e, TPS deluje prisilno.<\/p>\n

Soft<\/p>\n

64 % od minFree<\/p>\n

TPS + Balloon<\/p>\n

Trda<\/p>\n

32 % od minFree<\/p>\n

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

Low<\/p>\n

16 % od minFree<\/p>\n

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

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

minFree je pomnilnik, potreben za delovanje hipervizorja. <\/p>\n

Do ESXi 4.1 je bil minFree privzeto fiksiran \u2013 6 % od zmogljivosti pomnilnika stre\u017enika (percento se je dalo spremeniti preko mo\u017enosti Mem.MinFreePct na ESXi). V novej\u0161ih razli\u010dicah se je zaradi rasti koli\u010din pomnilnika na stre\u017enikih minFree za\u010delo izra\u010dunavati glede na koli\u010dino pomnilnika gostitelja, ne pa kot fiksna procentualna vrednost. <\/p>\n

Vrednost minFree (privzeto) se izra\u010duna na naslednji na\u010din:<\/p>\n

Procent pomnilnika, rezerviranega za minFree<\/b><\/p>\n

Obseg pomnilnika<\/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

Preostali pomnilnik<\/p>\n

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

Na primer, za stre\u017enik s 128 GB RAM je minFree naslednja:
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
\nDejanska vrednost se lahko razlikuje za nekaj sto MB, odvisno od stre\u017enika in pomnilnika.<\/p>\n

Procent pomnilnika, rezerviranega za minFree<\/b><\/p>\n

Obseg pomnilnika<\/b><\/p>\n

Vrednost 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

Preostali pomnilnik (100 GB)<\/p>\n

1024 MB<\/p>\n

\nObi\u010dajno za produktivne stojnice velja, da je normalno stanje le visoko. Za testne in razvojne stojnice so sprejemljiva stanja Clear\/Soft. \u010ce je na gostitelju ostalo manj kot 64 % MinFree, imajo VM-ji, ki delujejo na njem, gotovo te\u017eave z zmogljivostjo.<\/p>\n

V vsakem stanju se uporabljajo dolo\u010dene tehnike za pridobivanje pomnilnika, od TPS, ki prakti\u010dno ne vpliva na zmogljivost VM, do Swappinga. O njih bom podrobneje spregovoril. <\/p>\n

Transparentna delitev strani (TPS).<\/b> TPS je, preprosto re\u010deno, deduplikacija strani delovne pomnilnika virtualnih strojov na stre\u017eniku.<\/p>\n

ESXi i\u0161\u010de enake strani delovnega pomnilnika virtualnih strojev, pri \u010demer izra\u010duna in primerja hash obremenitev strani ter odstrani duplikate strani, jih zamenja z referencami na isto stran v fizi\u010dnem pomnilniku stre\u017enika. Tako se zmanj\u0161a poraba fizi\u010dnega pomnilnika in dose\u017ee dolo\u010dena prenova pomnilnika prakti\u010dno brez izgube zmogljivosti.<\/p>\n

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

Ta mehanizem deluje le za strani pomnilnika velikosti 4 Kb (majhne strani). Hiperkrmilnik niti ne posku\u0161a deduplikirati strani velikosti 2 Mb (velike strani), saj je verjetnost, da bi na\u0161el enake strani te velikosti, majhna.<\/p>\n

Privzeto ESXi dodeli pomnilnik velikim stranem. Razdelitev velikih strani na male se za\u010dne ob doseganju praga stanja High in se zgodi prisilno, ko se dose\u017ee stanje Clear (glejte tabelo stanj hipervizorja).<\/p>\n

\u010ce pa \u017eelite, da TPS za\u010dne delovati, ne da bi \u010dakal na napolnitev delovnega pomnilnika gostitelja, v raz\u0161irjenih mo\u017enostih ESXi nastavite vrednost \u201cMem.AllocGuestLargePage\u201d<\/i> na 0 (privzeto 1). Tako bo dodeljevanje velikih strani pomnilnika za virtualne stroje onemogo\u010deno.<\/p>\n

Od decembra 2014 je v vseh razli\u010dicah ESXi TPS med VM privzeto onemogo\u010den, ker je bila ugotovljena ranljivost, ki teoreti\u010dno omogo\u010da dostop do delovnega pomnilnika druge VM iz ene VM. Podrobnosti tukaj. O prakti\u010dni uporabi ranljivosti TPS nisem zasledil informacij.<\/p>\n

Politika TPS se upravlja preko raz\u0161irjene mo\u017enosti \u201cMem.ShareForceSalting\u201d<\/i> na ESXi:
\n0 \u2014 Inter-VM TPS. TPS deluje za strani razli\u010dnih VM;
\n1 \u2013 TPS za VM z enako vrednostjo \u201csched.mem.pshare.salt\u201d v VMX;
\n2 (privzeto) \u2013 Intra-VM TPS. TPS deluje za strani znotraj VM.<\/p>\n

Obvezno je smiselno izklopiti velike strani in omogo\u010diti Inter-VM TPS na testnih platformah. To se lahko uporablja tudi za platforme z veliko enakih VM. Na primer, na platformah z VDI lahko prihranek fizi\u010dnega pomnilnika dose\u017ee ve\u010d deset odstotkov. <\/p>\n

Pomnilni\u0161ko baloniranje.<\/b> Ballooning ni \u017ee ni tako nedol\u017ena in prozorna za operacijski sistem VM tehnika, kot je TPS. A ob pravilni uporabi lahko \u017eivimo in celo delamo z Ballooningom.<\/p>\n

Skupaj z Vmware Tools se na VM namesti poseben gonilnik, imenovan Balloon Driver (tudi vmmemctl). Ko hipervizorju za\u010dne primanjkovati fizi\u010dne pomnilnike in preide v stanje Soft, ESXi prosi VM, da vrne neuporabljeno operativno pomnilnik preko tega Balloon Driverja. Gonilnik na svojo stran deluje na ravni operacijskega sistema in od njega zahteva prost pomnilnik. Hipervizor vidi, katere strani fizi\u010dnega pomnilnika je zasedel Balloon Driver, vzame pomnilnik od virtualne naprave in ga vrne gostitelju. Te\u017eave z delovanjem OS ne nastanejo, saj je na ravni OS pomnilnik zaseden z Balloon Driverjem. Privzeto Balloon Driver lahko vzame do 65% pomnilnika VM.<\/p>\n

\u010ce na VM niso name\u0161\u010deni VMware Tools ali je Ballooning onemogo\u010den (ne priporo\u010dam, a je mo\u017eno KB<\/a><\/noindex>:), hipervizor takoj preide na ostrej\u0161e tehnike odvzema pomnilnika. Zaklju\u010dek: poskrbite, da bodo VMware Tools name\u0161\u010deni na VM.<\/p>\n

\"Analiza
\nDelovanje Balloon Driverja lahko preverite iz OS preko VMware Tools.<\/i>.<\/p>\n

Stiskanje pomnilnika.<\/b> Ta tehnika se uporablja, ko ESXi dose\u017ee stanje Hard. Kot pove \u017ee ime, ESXi posku\u0161a stisniti 4 Kbyte strani operativne pomnilnika na 2 Kbyte in tako osvoboditi malo prostora v fizi\u010dnem pomnilniku stre\u017enika. Ta tehnika znatno pove\u010da \u010das dostopa do vsebine strani operativne pomnilnika VM, saj je treba stran prej raz\u0161iriti. V\u010dasih se ne vse strani uspe stisniti in sam postopek traja nekaj \u010dasa. Zato ta tehnika v praksi ni zelo u\u010dinkovita.<\/p>\n

Zamenjava pomnilnika.<\/b> Po kratkem obdobju stiskanja pomnilnika ESXi skoraj neizogibno (\u010de VM niso od\u0161le na druge gostitelje ali se niso izklopile) preide na zamenjavo. In \u010de pomnilnika zares malo ostane (stanje Low), hipervizor preneha dodeljevati VM strani pomnilnika, kar lahko povzro\u010di te\u017eave v gostujo\u010dih OS VM.<\/p>\n

Tako deluje Swapping. Ko se aktivira virtualni stroj, se ustvari datoteka z raz\u0161iritvijo .vswp. Njena velikost ustreza neza\u0161\u010denemu delovnemu pomnilniku VM: to je razlika med konfiguriranim in rezerviranim pomnilnikom. Med delovanjem Swappinga ESXi prenese strani pomnilnika virtualnega stroja v to datoteko in za\u010dne delovati z njo namesto s fizi\u010dnim pomnilnikom stre\u017enika. Seveda je tak\u0161na 'operativna' pomnilnost veliko po\u010dasnej\u0161a od prave, tudi \u010de .vswp le\u017ei na hitrem shranjevanju.<\/p>\n

Za razliko od Ballooninga, ko se VM odvzamejo neizkori\u0161\u010dene strani, lahko pri Swappingu na disk preidejo strani, ki jih aktivno uporablja OS ali aplikacije znotraj VM. Posledi\u010dno se zmogljivost VM zmanj\u0161a, vse do zamrznitve. VM formalno deluje in jo je vsaj mogo\u010de pravilno izklopiti iz OS. \u010ce boste potrpe\u017eljivi \ud83d\ude09<\/p>\n

\u010ce je VM pre\u0161la v Swap \u2014 je to izredna situacija, ki ji je bolje prepre\u010diti, kolikor je mogo\u010de.<\/p>\n

Glavni kazalniki zmogljivosti pomnilnika virtualnega stroja<\/h3>\n

\nPravkar smo pri\u0161li do glavnega. Za spremljanje stanja pomnilnika v VM obstajajo naslednji kazalniki:<\/p>\n

Active<\/b> \u2014 prikazuje obseg delovnega pomnilnika (KB), do katerega je VM imela dostop v prej\u0161njem merilnem obdobju.<\/p>\n

Usage<\/b> \u2014 enako kot Active, vendar v odstotkih od konfiguriranega delovnega pomnilnika VM. Izra\u010duna se po naslednji formuli: active \u00f7 velikost konfiguriranega pomnilnika virtualnega stroja.
\nVisok Usage in Active nista nujno pokazatelja te\u017eav z zmogljivostjo VM. \u010ce VM agresivno uporablja pomnilnik (vsaj dostopa do njega), to ne pomeni, da pomnilnik primanjkuje. Raje je to razlog, da pogledate, kaj se dogaja v OS.
\nObstaja standardni Alarm za Memory Usage za VM:<\/p>\n

\"Analiza
\n
\nSkupna<\/b> \u2014 obseg delovnega pomnilnika VM, dedupliciran s pomo\u010djo TPS (znotraj VM ali med VM).<\/p>\n

Granted<\/b> \u2014 obseg fizi\u010dnega pomnilnika gostitelja (KB), ki je bil dodeljen VM. Vklju\u010duje Shared.<\/p>\n

Consumed<\/b> (Granted \u2014 Shared) \u2014 obseg fizi\u010dnega pomnilnika (KB), ki ga VM porabi s gostitelja. Ne vklju\u010duje Shared.<\/p>\n

\u010ce del pomnilnika VM ne izhaja iz fizi\u010dnega pomnilnika gostitelja, ampak iz swap datoteke ali je pomnilnik odvzet VM preko Balloon Driverja, ta obseg ni upo\u0161tevan v Granted in Consumed.
\nVisoka vrednost Granted in Consumed je povsem normalna. Operacijski sistem postopoma odvzema spomin hipervizorju in ga ne vra\u010da. S\u010dasoma se pri aktivni VM vrednosti teh merilnikov pribli\u017eajo prostornini konfigurirane pomnilnika in tam ostanejo.<\/p>\n

Zero<\/b> \u2014 koli\u010dina delovnega pomnilnika VM (Kbyte), ki vsebuje ni\u010dle. Tak\u0161en pomnilnik hipervizor obravnava kot prost in ga lahko dodeli drugim virtualnim strojema. Ko operacijski sistem gostitelja zapi\u0161e kaj v ponastavljeni pomnilnik, preide v Consumed in se nazaj ne vrne.<\/p>\n

Reserved Overhead<\/b> \u2014 koli\u010dina delovnega pomnilnika VM (Kbyte), ki jo hipervizor rezervira za delovanje VM. To je majhna koli\u010dina, vendar mora obstajati na gostitelju, sicer VM ne bo zagnan.<\/p>\n

Balloon<\/b> \u2014 koli\u010dina delovnega pomnilnika (Kbyte), ki je bila odvzeta VM s pomo\u010djo Balloon Driverja.<\/p>\n

Compressed<\/b> \u2014 koli\u010dina delovnega pomnilnika (Kbyte), ki jo je uspelo stisniti.<\/p>\n

Swapped<\/b> \u2014 koli\u010dina delovnega pomnilnika (Kbyte), ki je zaradi pomanjkanja fizi\u010dnega pomnilnika na stre\u017eniku pre\u0161la na disk.
\nBalloon in ostale merilnike tehnik vra\u010danja pomnilnika so enake ni\u010d.<\/p>\n

Tako izgleda graf s \u0161tevilkami Memory normalno delujo\u010de VM s 150 GB delovnega pomnilnika.<\/p>\n

\"Analiza
\n
\nNa grafu spodaj ima VM o\u010ditne te\u017eave. Pod grafom je razvidno, da so za to VM bile uporabljene vse opisane tehnike dela z delovnim pomnilnikom. Balloon za to VM je bistveno ve\u010dji od Consumed. Dejansko je VM bolj mrtva kot \u017eiva. <\/p>\n

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

ESXTOP<\/h3>\n

\nKot pri CPU, \u010de \u017eelimo hitro oceniti situacijo na gostitelju in njeno dinamiko s \u010dasovnim intervalom do 2 sekund, je smiselno uporabiti ESXTOP.<\/p>\n

Zaslon ESXTOP za Memory se aktivira s tipko 'm' in izgleda takole (izbrane so polja B, D, H, J, K, L, O):<\/p>\n

\"Analiza
\n
\nZanimali nas bodo naslednji parametri: <\/p>\n

Mem overcommit avg<\/b> \u2014 povpre\u010dna vrednost preobremenitve pomnilnika na gostitelju v zadnjem 1, 5 in 15 minutah. \u010ce je vi\u0161ja od ni\u010d, je to razlog za razmislek o tem, kaj se dogaja, vendar ne vedno dokazuje obstoj te\u017eav.<\/p>\n

V vrsticah PMEM\/MB<\/b> in VMKMEM\/MB<\/b> \u2014 informacije o fizi\u010dnem pomnilniku stre\u017enika in pomnilniku, dostopnem VMkernelu. Interesantno je videti vrednost minfree (v MB), stanje gostitelja glede pomnilnika (v na\u0161em primeru, visoko).<\/p>\n

V vrstici NUMA\/MB<\/b> lahko vidimo razporeditev delovnega pomnilnika po NUMA vozlih (soketih). V tem primeru razporeditev ni enakomerna, kar na\u010deloma ni dobro.<\/p>\n

Nasledije daje op\u0161te statistike o serveru o tehnikama vra\u0107anja memorije:<\/p>\n

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

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

ZIP\/MB<\/b> \u2014 statistika kompresije stranica memorije;<\/p>\n

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

Za svaku VM, mo\u017eemo biti zainteresovani za slede\u0107e informacije. Imena VM sam sakrio, kako ne bih zbunio publiku :). Ako je metrika ESXTOP sli\u010dna broja\u010du u vSphere, navodim odgovaraju\u0107i broja\u010d. <\/p>\n

MEMSZ<\/b> \u2014 ukupna memorija, konfigurirana za VM (MB).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

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

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

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

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

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

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

SWCUR<\/b> \u2014 trenutna koli\u010dina RAM-a (MB), koja je data VM-u iz Swap fajla. <\/p>\n

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

Tako\u0111e, putem ESXTOP-a mo\u017eete pogledati detaljnije informacije o NUMA topologiji VM-a. Za to treba odabrati polja D,G:<\/p>\n

\"Analiza
\n
\nNHN<\/b> \u2013 NUMA \u010dvorovi na kojima je sme\u0161ten VM. Ovde se odmah mogu primetiti \u0161iroki VM-ovi, koji ne mogu stati na jedan NUMA \u010dvor.<\/p>\n

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

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

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

Memorija na hipervizoru<\/h3>\n

\nAko CPU broja\u010di na hipervizoru obi\u010dno ne predstavljaju poseban interes, situacija sa memorijom je suprotna. Visoka potro\u0161nja memorije na VM-u ne zna\u010di uvek da postoji problem sa performansama, ali visoka potro\u0161nja memorije na hipervizoru pokre\u0107e tehnike upravljanja memorijom i izaziva probleme sa performansama VM-a. Potrebno je pratiti alarmirane Host Memory Usage i ne dozvoliti da VM do\u0111e u Swap.<\/p>\n

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

Unswap<\/h3>\n

\nAko VM do\u0111e u Swap, njena performansa se zna\u010dajno smanjuje. Tragovi Ballooning-a i kompresije brzo nestaju nakon \u0161to se slobodna RAM na hostu pojavi, ali vra\u0107anje iz Swapa u RAM servera virtuelna ma\u0161ina ne \u017euri.
\nDo razli\u010dice ESXi 6.0 je bil edini zanesljiv in hiter na\u010din za izhod VM iz Swap-a ponovno zagon (natan\u010dneje izklop\/ vklop kontejnerja). Za\u010den\u0161i z ESXi 6.0 se je pojavil \u0161e ne popolnoma uraden, a delujo\u010d in zanesljiv na\u010din za izhod VM iz Swap-a. Na eni izmed konferenc sem imel prilo\u017enost govoriti z enim od in\u017eenirjev VMware, ki je odgovoren za CPU Scheduler. Potrdil je, da je metoda povsem delujo\u010da in varna. V na\u0161em primeru nismo imeli te\u017eav z njo.<\/p>\n

Dejansko ukaz za izhod VM iz Swap-a opisal<\/a><\/noindex> Duncan Epping. Ne bom ponavljal podrobnega opisa, samo navedel bom primer njene uporabe. Kot je razvidno na posnetku zaslona, po dolo\u010denem \u010dasu po izvedbi navedenega ukaza Swap na VM izgine.<\/p>\n

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

Nasveti za upravljanje z operativno pomnilnikom v ESXi<\/h3>\n

\nNa koncu bom navedel nekaj nasvetov, ki vam bodo pomagali prepre\u010diti te\u017eave s hitrostjo VM zaradi operativne pomnilnika:<\/p>\n