{"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\/et\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"VM-i j\u00f5udluse anal\u00fc\u00fcs VMware vSphere'is. Osa 2: M\u00e4lu","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VM-i
\n
\nOsa 1. CPU-st<\/a><\/noindex><\/p>\n

Selles artiklis r\u00e4\u00e4gime vSphere'is t\u00f6\u00f6tava RAM-i j\u00f5udlusloenduritest.
\nM\u00e4lu osas tundub k\u00f5ik olevat selgem, kui protsessori osas: kui VM-ides esinevad j\u00f5udlusprobleemid, on neid raske mitte m\u00e4rgata. Kui need aga ilmnevad, on nende lahendamine palju keerulisem. Aga v\u00f5tame k\u00f5ik etappid j\u00e4rjest. <\/a><\/noindex><\/p>\n

Natuke teooriat<\/h3>\n

\nVirtuaalmasinate t\u00f6\u00f6m\u00e4lu tuleb serveri m\u00e4lust, millel masinad t\u00f6\u00f6tavad. See on t\u00e4iesti arusaadav:). Kui serveri t\u00f6\u00f6m\u00e4lu ei piisa k\u00f5igile soovijatele, hakkab ESXi rakendama m\u00e4lu optimeerimise tehnikaid (memory reclamation techniques). Vastasel juhul kukuksid operatsioonis\u00fcsteemid m\u00e4lu juurde p\u00e4\u00e4semise vigade t\u00f5ttu. <\/p>\n

Milliseid tehnikaid rakendada, otsustab ESXi m\u00e4lu koormuse p\u00f5hjal:<\/p>\n

M\u00e4lu seisund<\/b><\/p>\n

Piir<\/b><\/p>\n

Toimingud<\/b><\/p>\n

K\u00f5rge<\/p>\n

400% minFree'ist<\/p>\n

Peale \u00fclemise piiri saavutamist jagatakse suured m\u00e4lulehed v\u00e4ikesteks (TPS t\u00f6\u00f6tab tavalises re\u017eiimis).<\/p>\n

Puhasta<\/p>\n

100% minFree'ist<\/p>\n

Suured m\u00e4lulehed jagatakse v\u00e4ikesteks, TPS t\u00f6\u00f6tab sundimisega.<\/p>\n

Pehme<\/p>\n

64% minFree'ist<\/p>\n

TPS + Balloon<\/p>\n

K\u00f5va<\/p>\n

32% minFree'ist<\/p>\n

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

Madal<\/p>\n

16% minFree'ist<\/p>\n

Kao + Vahetus + Plokk<\/p>\n

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

minFree \u2014 see on m\u00e4lu, mis on vajalik h\u00fcperviisori t\u00f6\u00f6ks. <\/p>\n

Kuni ESXi 4.1 oli minFree vaikimisi fikseeritud \u2014 6% serveri m\u00e4lust (protsenti sai muuta valiku Mem.MinFreePct kaudu ESXi-s). Hilisemates versioonides, arvestades serverite m\u00e4lu suurenenud mahtu, arvutatakse minFree hosti m\u00e4lust, mitte kui fikseeritud protsent. <\/p>\n

minFree (vaikimisi) v\u00e4\u00e4rtus arvutatakse j\u00e4rgmiselt:<\/p>\n

Protsent m\u00e4lust, mis on reserveeritud minFree jaoks<\/b><\/p>\n

M\u00e4lupiirang<\/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

J\u00e4relej\u00e4\u00e4nud m\u00e4lu<\/p>\n

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

N\u00e4iteks, 128 GB RAM-iga serveri minFree v\u00e4\u00e4rtus oleks j\u00e4rgmine:
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
\nTegelik v\u00e4\u00e4rtus v\u00f5ib erineda paarisajas MB v\u00f5rra, s\u00f5ltuvalt serverist ja m\u00e4lust.<\/p>\n

Protsent m\u00e4lust, mis on reserveeritud minFree jaoks<\/b><\/p>\n

M\u00e4lupiirang<\/b><\/p>\n

128 GB v\u00e4\u00e4rtus<\/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

J\u00e4relej\u00e4\u00e4nud m\u00e4lu (100 GB)<\/p>\n

1024 MB<\/p>\n

\nTavaliselt peetakse produktiivsete serverite jaoks normaalseks ainult k\u00f5rge oleku. Testimis- ja arenduss\u00fcsteemide puhul v\u00f5ivad vastuv\u00f5etavad olekud olla Clear\/Soft. Kui hostis on v\u00e4hemalt 64% MinFree vahem\u00e4lu alles, siis toimuvad sellel p\u00f5hinevate VM-ide puhul t\u00f5en\u00e4oliselt j\u00f5udlusprobleemid.<\/p>\n

Igas olekus rakendatakse teatud m\u00e4lu taaskasutamise tehnikaid, alates TPS-ist, mis praktiliselt ei m\u00f5juta VM-i j\u00f5udlust, kuni Swappinguni. R\u00e4\u00e4gin neist l\u00e4hemalt. <\/p>\n

L\u00e4bipaistev lehe jagamine (TPS).<\/b> TPS on, julgelt \u00f6eldes, virtuaalmasinate m\u00e4lulehtede dedupeerimine serveris.<\/p>\n

ESXi otsib sarnaseid virtuaalmasinate m\u00e4lulehti, arvutades ja v\u00f5rdledes lehtede hash-summasid ning eemaldab dubleeritud lehed, asendades need viidete t\u00f5ttu sama lehega f\u00fc\u00fcsilises m\u00e4lus. Selle tulemusena v\u00e4heneb f\u00fc\u00fcsilise m\u00e4lu tarbimine ja on v\u00f5imalik saavutada teatud m\u00e4lude \u00fcmberkirjutamine praktiliselt ilma j\u00f5udluse languseta.<\/p>\n

\"VM-i
\nAllikas<\/a><\/noindex><\/p>\n

Seda mehhanism t\u00f6\u00f6tab ainult 4 KB (v\u00e4ikesed lehed) m\u00e4lulehtede jaoks. 2 MB (suured lehed) lehtede puhul ei \u00fcrita h\u00fcperviisor deduplikatsiooni isegi teha, kuna sama suurusega lehtede leidmise v\u00f5imalus on v\u00e4ike.<\/p>\n

Vaikimisi eraldab ESXi m\u00e4lu suurtele lehtedele. Suurte lehtede jagamine v\u00e4ikesteks algab, kui saavutatakse k\u00f5rge olek, ja toimub sunniviisiliselt, kui saavutatakse selge olek (vt h\u00fcperviisori olekute tabelit).<\/p>\n

Kui soovite, et TPS alustaks t\u00f6\u00f6d, ootamata hosti operaatorm\u00e4lu t\u00e4itumist, peate ESXi T\u00e4iustatud valikutes seadma v\u00e4\u00e4rtuse \u201cMem.AllocGuestLargePage\u201d<\/i> 0-le (vaikimisi 1). Sel juhul keelatakse suurte m\u00e4lulehtede eraldamine virtuaalmasinatele.<\/p>\n

Alates 2014. aasta detsembrist on k\u00f5igis ESXi v\u00e4ljaannetes TPS vahel VM-de vahel vaikimisi keelatud, kuna leiti haavatavus, mis teoreetiliselt v\u00f5imaldab saada \u00fche VM-i kaudu teise VM-i operaatorm\u00e4lu. \u00dcksikasjad siin. Ma ei ole kohanud teavet TPS haavatavuse praktilise rakendamise kohta.<\/p>\n

TPS poliitikat kontrollitakse l\u00e4bi t\u00e4iustatud valiku \u201cMem.ShareForceSalting\u201d<\/i> ESXi-s:
\n0 \u2014 Inter-VM TPS. TPS t\u00f6\u00f6tab erinevate VM-ide lehtede jaoks;
\n1 \u2013 TPS sama 'sched.mem.pshare.salt' v\u00e4\u00e4rtusega VM-ide jaoks VMX-is;
\n2 (vaikimisi) \u2013 Intra-VM TPS. TPS t\u00f6\u00f6tab lehtede jaoks VM-i sees.<\/p>\n

On h\u00e4davajalik v\u00e4lja l\u00fclitada suured lehed ja aktiveerida Inter-VM TPS testimisjaamades. Seda saab kasutada ka jaamades, kus on palju sarnaseid VM-e. N\u00e4iteks VDI jaamades v\u00f5ib f\u00fc\u00fcsilise m\u00e4lu kokkuhoid ulatuda k\u00fcmnete protsentideni. <\/p>\n

Memory Ballooning.<\/b> Ballooning ei ole enam nii s\u00fc\u00fctuks ja l\u00e4bipaistvaks operatsioonis\u00fcsteemile VM-i tehnika nagu TPS. Kuid \u00f5igesti rakendades on Ballooninguga v\u00f5imalik elada ja isegi t\u00f6\u00f6tada.<\/p>\n

Koos Vmware Tools installitakse VM-ile spetsiaalne juhtmega, mida nimetatakse Balloon Driveriks (aka vmmemctl). Kui h\u00fcperviisoril hakkab f\u00fc\u00fcsilisest m\u00e4lust puudu j\u00e4\u00e4ma ja ta l\u00e4heb Soft olekusse, palub ESXi VM-l vabastada mittekasutatav RAM l\u00e4bi selle Balloon Driveri. Juhtme t\u00f6\u00f6tab omakorda operatsioonis\u00fcsteemi tasemel ja k\u00fcsib vabade m\u00e4lublokkide kohta. H\u00fcperviisor n\u00e4eb, millised f\u00fc\u00fcsilised m\u00e4lulehed on Balloon Driveri poolt h\u00f5ivatud, v\u00f5tab m\u00e4lumoodulite virtuaalsest masinast ja tagastab hostile. Probleeme operatsioonis\u00fcsteemi t\u00f6\u00f6ga ei teki, kuna operatsioonis\u00fcsteemi tasandil on m\u00e4lu h\u00f5ivatud Balloon Driveri poolt. Vaikimisi saab Balloon Driver v\u00f5tta kuni 65% VM-i m\u00e4lust.<\/p>\n

Kui VM-il ei ole installitud VMware Tools v\u00f5i on Ballooning v\u00e4lja l\u00fclitatud (mida ei soovita, kuid on olemas KB<\/a><\/noindex>:), siis h\u00fcperviisor l\u00e4heb kohe \u00fcle rangematele m\u00e4lueemaldustehnikatele. J\u00e4reldus: veenduge, et VMware Tools oleksid VM-il olemas.<\/p>\n

\"VM-i
\nBalloon Driveri t\u00f6\u00f6d saab kontrollida OS-ist l\u00e4bi VMware Tools<\/i>.<\/p>\n

Memory Compression.<\/b> Seda meetodit kasutatakse, kui ESXi j\u00f5uab Hard olekusse. Nagu nimi viitab, p\u00fc\u00fcab ESXi suruda 4 KB t\u00f6\u00f6tlemism\u00e4lu lehte 2 KB-ks, et vabastada serveri f\u00fc\u00fcsilises m\u00e4lus natuke ruumi. See tehnika suurendab oluliselt VM-i t\u00f6\u00f6tlemism\u00e4lu lehtede sisu k\u00e4tte saamise aega, kuna lehte tuleb eelnevalt dekompressida. M\u00f5nikord ei \u00f5nnestu k\u00f5iki lehti kokku suruda ja kogu protsess v\u00f5tab aega. Seet\u00f5ttu ei ole see tehnika praktikas eriti efektiivne.<\/p>\n

M\u00e4lu vahetamine.<\/b> P\u00e4rast l\u00fchikest M\u00e4lu kokkusurumise etappi l\u00e4heb ESXi praktiliselt v\u00e4ltimatult (kui VM-id ei ole teistesse hostidesse liikunud v\u00f5i v\u00e4lja l\u00fclitatud) \u00fcle vahetamisele. Ja kui m\u00e4lu on peaaegu otsas (Low olek), l\u00f5petab h\u00fcperviisor samuti VM-ide m\u00e4lu lehtede eraldamise, mis v\u00f5ib p\u00f5hjustada probleeme VM-i k\u00fclaliste operatsioonis\u00fcsteemides.<\/p>\n

Nii t\u00f6\u00f6tab vahetus. Kui virtuaalmasin k\u00e4ivitub, luuakse tema jaoks laiendiga .vswp fail. Selle suurus on sama, mis VM-i mittereserveeritud m\u00e4lu: see on vahe konfigureeritud ja reserveeritud m\u00e4luhulga vahel. Vahetuse toimimise ajal laadib ESXi virtuaalmasina m\u00e4lulehed sellesse faili ja hakkab sellega t\u00f6\u00f6tama f\u00fc\u00fcsilise serveri m\u00e4lu asemel. Loomulikult on selline \"m\u00e4lu\" mitu korda aeglasem kui t\u00f5eline, isegi kui .vswp asub kiirel salvestusruumil.<\/p>\n

Erinevalt Ballooningust, mille puhul VM-ilt v\u00f5etakse tagasi kasutamata lehed, v\u00f5ivad vahetuse korral kettale minna ka lehed, mida operatsioonis\u00fcsteem v\u00f5i rakendused seespool VM-i aktiivselt kasutavad. Selle tulemusena tr\u00ean j\u00f5udlus langeb kuni kokkujooksmiseni. VM t\u00f6\u00f6tab formaalselt ja seda on v\u00e4hemalt v\u00f5imalik \u00f5igesti v\u00e4lja l\u00fclitada operatsioonis\u00fcsteemist. Kui olete kannatlik \ud83d\ude09<\/p>\n

Kui VM-id on vahetusse l\u00e4inud, on see ebanormaalne olukord, mida oleks parem v\u00e4ltida.<\/p>\n

Virtuaalmasina m\u00e4lu peamised j\u00f5udlusm\u00f5\u00f5dikud<\/h3>\n

\nN\u00fc\u00fcd oleme peamise teema juures. VM-i m\u00e4lastaatuse j\u00e4lgimiseks on j\u00e4rgmised m\u00f5\u00f5dikud:<\/p>\n

Active<\/b> \u2014 n\u00e4itab m\u00e4lu mahtu (KB), millele VM p\u00e4\u00e4ses juurde eelneva m\u00f5\u00f5tmise ajal.<\/p>\n

Kasutus<\/b> \u2014 sama, mis Active, kuid protsentides VM-i konfigureeritud m\u00e4lust. Arvutatakse j\u00e4rgmise valemi j\u00e4rgi: active \u00f7 virtuaalmasina konfigureeritud m\u00e4lumaht.
\nK\u00f5rge Usage ja Active ei ole alati n\u00e4itajaid VM-i j\u00f5udlusprobleemide jaoks. Kui VM kasutab m\u00e4lu agressiivselt (kui v\u00e4hemalt p\u00e4\u00e4seb sellele juurde), ei t\u00e4henda see, et m\u00e4lu on ebapiisav. Pigem on see p\u00f5hjus, miks vaadata, mis OS-is toimub.
\nVM-i jaoks on saadaval standard Alarm m\u00e4lu kasutamise kohta:<\/p>\n

\"VM-i
\n
\nJagatud<\/b> \u2014 VM-i m\u00e4lu maht, mis on dedupliceeritud TPS-iga (kas VM-i sees v\u00f5i VM-ide vahel).<\/p>\n

Antud<\/b> \u2014 f\u00fc\u00fcsiline m\u00e4lu (KB) hostis, mis on antud VM-ile. Sisaldab Shared.<\/p>\n

Tarbitud<\/b> (Granted \u2014 Shared) \u2014 f\u00fc\u00fcsiline m\u00e4lu (KB), mida VM hostilt tarbib. Ei sisalda Shared.<\/p>\n

Kui osa VM-i m\u00e4lust antakse mitte f\u00fc\u00fcsilisest m\u00e4lust hostis, vaid vahetust failist v\u00f5i m\u00e4lu on VM-ilt \u00e4ra v\u00f5etud Balloon Driveri kaudu, siis seda mahtu ei arvestata Granted ega Consumed.
\nK\u00f5rged Granted ja Consumed v\u00e4\u00e4rtused on t\u00e4iesti normaalsed. Operatsioonis\u00fcsteem t\u00f5mbab j\u00e4rk-j\u00e4rgult m\u00e4luruumi h\u00fcperviisorilt tagasi ja ei anna seda enam tagasi. Aja jooksul, kui virtuaalne masin aktiivselt t\u00f6\u00f6tab, l\u00e4heneb nende n\u00e4itajate v\u00e4\u00e4rtus konfigureeritud m\u00e4lu mahule ja j\u00e4\u00e4b sinna.<\/p>\n

Null<\/b> \u2014 VM (KB) m\u00e4lu maht, mis sisaldab nullide v\u00e4\u00e4rtusi. Sellist m\u00e4lu peab h\u00fcperviisor vabaks ja see v\u00f5ib olla muudele virtuaalsetele masinatele eraldatud. P\u00e4rast seda, kui k\u00fclghaldus s\u00fcsteem on midagi nullitud m\u00e4llu salvestanud, l\u00e4heb see Consumed seisundisse ja enam tagasi ei naase.<\/p>\n

Reserved Overhead<\/b> \u2014 VM (KB) m\u00e4lu maht, mis on h\u00fcperviisori poolt VM t\u00f6\u00f6ks reserveeritud. See on v\u00e4ike maht, kuid see peab olema hostis olemas, vastasel juhul ei k\u00e4ivitu VM.<\/p>\n

Balloon<\/b> \u2014 m\u00e4lu maht (KB), mis on VM-lt saadud Balloon Driveri abil v\u00e4lja v\u00f5etud.<\/p>\n

Compressed<\/b> \u2014 m\u00e4lu maht (KB), mida \u00f5nnestus kompressida.<\/p>\n

Swapped<\/b> \u2014 m\u00e4lu maht (KB), mis f\u00fc\u00fcsilise m\u00e4lu puudumisel serveris on diskile \u00fcle viidud.
\nBalloon ja muud m\u00e4lu tagastamise tehnika n\u00e4itajad on null.<\/p>\n

Nii n\u00e4eb v\u00e4lja m\u00e4lu t\u00f6\u00f6kindla VM-i n\u00e4itaja graafik, millel on 150 GB RAM-i.<\/p>\n

\"VM-i
\n
\nAlloleval graafikul on VM-il selged probleemid. Graafiku all on n\u00e4ha, et selle VM-i jaoks on kasutatud k\u00f5iki kirjeldatud tehnikaid m\u00e4luga t\u00f6\u00f6tamiseks. Balloon on selle VM-i jaoks palju suurem kui tarbitud. Tegelikult on VM pigem surnud kui elus. <\/p>\n

\"VM-i
\n<\/p>\n

ESXTOP<\/h3>\n

\nNagu ka CPU puhul, kui soovime kiiresti hinnata hosti olukorda ja selle d\u00fcnaamikat kuni 2 sekundi intervalliga, tasub kasutada ESXTOPi.<\/p>\n

M\u00e4lu ESXTOP ekraan avatakse klahviga \u201em\u201c ja see n\u00e4eb v\u00e4lja j\u00e4rgmine (valitud v\u00e4ljad B, D, H, J, K, L, O):<\/p>\n

\"VM-i
\n
\nMeid huvitavad j\u00e4rgmised parameetrid: <\/p>\n

Mem overcommit avg<\/b> \u2014 keskmine m\u00e4lust \u00fclekoormus hostis 1, 5 ja 15 minuti jooksul. Kui see on \u00fcle nulli, on see p\u00f5hjus vaadata, mis toimub, kuid see ei pruugi alati t\u00e4hendada probleemide olemasolu.<\/p>\n

Rea PMEM\/MB<\/b> ja VMKMEM\/MB<\/b> \u2014 teave serveri f\u00fc\u00fcsilise m\u00e4lu ja VMkernelile \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0439 m\u00e4lu kohta. Siit saab n\u00e4ha huvitavat v\u00e4\u00e4rtust minfree (MB-des) ja hosti m\u00e4lu seisundit (meie puhul k\u00f5rge).<\/p>\n

Reas NUMA\/MB<\/b> numa-s\u00f5lmedes (socketites) on v\u00f5imalik n\u00e4ha operatiivm\u00e4lu jaotust. Antud n\u00e4ites on jaotus eba\u00fchtlane, mis \u00fcldiselt pole kuigi hea.<\/p>\n

J\u00e4rgnevalt on toodud \u00fcldine statistika serveri m\u00e4lurekonstruktsioonitehnoloogiate kohta:<\/p>\n

PSHARE\/MB<\/b> \u2014 see on TPS statistika;<\/p>\n

SWAP\/MB<\/b> \u2014 Swap-i kasutamise statistika;<\/p>\n

ZIP\/MB<\/b> \u2014 m\u00e4lu lehtede kokkusurumise statistika;<\/p>\n

MEMCTL\/MB<\/b> \u2014 Balloon Driveri kasutamise statistika.<\/p>\n

Erinevate VM-ide puhul v\u00f5ib meid huvitada j\u00e4rgmine teave. Olen VM-i nimesid varjanud, et mitte publikut segadusse ajada:). Kui ESXTOP-i metrika on sarnane vSphere\u2019i loenduriga, toon vastava loenduri. <\/p>\n

MEMSZ<\/b> \u2014 VM-ile konfigureeritud m\u00e4lu maht (MB).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

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

TCHD<\/b> \u2014 Aktiivsed MB-des.<\/p>\n

MCTL?<\/b> \u2014 kas Balloon Driver on VM-il seadistatud.<\/p>\n

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

MCTLGT<\/b> \u2014 operatiivm\u00e4lu maht (MB), mille ESXi soovib VM-ilt Balloon Driveri kaudu v\u00e4lja v\u00f5tta (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 maksimaalne operatiivm\u00e4lu maht (MB), mille ESXi v\u00f5ib VM-ilt Balloon Driveri kaudu v\u00e4lja v\u00f5tta.<\/p>\n

SWCUR<\/b> \u2014 praegune operatiivm\u00e4lu maht (MB), mis on VM-ile antud Swap-failist. <\/p>\n

SWGT<\/b> \u2014 operatiivm\u00e4lu maht (MB), mille ESXi soovib VM-ile anda Swap-failist (Swap Target).<\/p>\n

Samuti saab ESXTOP kaudu vaadata \u00fcksikasjalikumat teavet VM-i NUMA-topoloogia kohta. Selleks tuleb valida v\u00e4ljad D,G:<\/p>\n

\"VM-i
\n
\nNHN<\/b> \u2013 NUMA s\u00f5lmed, kus VM asub. Siit saab kohe t\u00e4hele panna wide vm-e, mis ei mahuks \u00fche NUMA s\u00f5lme.<\/p>\n

NRMEM<\/b> \u2013 mitu megabaiti m\u00e4lu v\u00f5tab VM kaugest NUMA s\u00f5lmest.<\/p>\n

NLMEM<\/b> \u2013 mitu megabaiti m\u00e4lu v\u00f5tab VM lokaalsest NUMA s\u00f5lmest.<\/p>\n

N%L<\/b> \u2013 protsent m\u00e4lu VM-is kohaliku NUMA s\u00f5lmes (kui alla 80% \u2014 v\u00f5ivad tekkida j\u00f5udlusprobleemid).<\/p>\n

M\u00e4lu h\u00fcperviisori peal<\/h3>\n

\nKui CPU loendurid h\u00fcperviisori peal ei ole tavaliselt kuigi huvitavad, siis m\u00e4lu olukord on vastupidine. K\u00f5rge Memory Usage VM-is ei pruugi alati t\u00e4hendada j\u00f5udlusprobleemi, kuid k\u00f5rge Memory Usage h\u00fcperviisori peal kutsub esile m\u00e4lu haldamise tehnikate t\u00f6\u00f6le asumise ja v\u00f5ib tekitada j\u00f5udlusprobleeme VM-is. Tuleb j\u00e4lgida Host Memory Usage h\u00e4ireid ning mitte lubada VM-il Swap'i sattuda.<\/p>\n

\"VM-i
\n
\n\"VM-i
\n<\/p>\n

Unswap<\/h3>\n

\nKui VM satub Swap'i, siis tema j\u00f5udlus langeb oluliselt. Ballooningu ja kompressiooni j\u00e4ljed kaovad kiiresti p\u00e4rast seda, kui hostis on vabade m\u00e4lude olemasolu, kuid VM ei kiirusta Swap'ist serveri m\u00e4llu tagasi tulema.
\nEnne ESXi 6.0 versiooni oli ainus usaldusv\u00e4\u00e4rne ja kiire viis VM-i Swap'ist v\u00e4lja saamiseks taask\u00e4ivitamine (t\u00e4psemalt konteineri v\u00e4ljal\u00fclitamine \/ sisse l\u00fclitamine). Alates ESXi 6.0-st on olemas kuigi mitte p\u00e4ris ametlik, aga t\u00f6\u00f6kindel ja efektiivne meetod VM-i Swap'ist v\u00e4lja toomiseks. \u00dchel konverentsil sain r\u00e4\u00e4kida \u00fche VMware inseneriga, kes vastutab CPU ajakava eest. Ta kinnitas, et meetod on t\u00e4iesti t\u00f6\u00f6kindel ja ohutu. Meie kogemustes pole sellega ka probleeme olnud.<\/p>\n

K\u00e4sk VM-i Swap'ist v\u00e4lja toomiseks kirjeldas<\/a><\/noindex> Duncan Epping. Ei hakka kordama p\u00f5hjalikku kirjeldust, lihtsalt toon v\u00e4lja n\u00e4ite selle kasutamisest. Nagu ekraanipildil n\u00e4ha, kaob antud k\u00e4su t\u00e4itmise j\u00e4rel m\u00f5ne aja p\u00e4rast Swap VM-ist.<\/p>\n

\"VM-i
\n<\/p>\n

N\u00f5uanded m\u00e4luhalduseks ESXi-l<\/h3>\n

\nL\u00f5puks jagan m\u00f5ned n\u00f5uanded, mis aitavad teil v\u00e4ltida VM-i j\u00f5udlusprobleeme, mis on seotud m\u00e4luga:<\/p>\n