{"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\/no\/blog\/administrirovanie\/analiz-proizvoditelnosti-vm-v-vmware-vsphere-chast-2-memory","title":{"rendered":"Analyse av ytelse av VM i VMware vSphere. Del 2: Minne","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Analyse
\n
\nDel 1. Om CPU<\/a><\/noindex><\/p>\n

I denne artikkelen skal vi snakke om ytelsesm\u00e5lere for RAM i vSphere.
\nDet virker som om minnet er litt mer entydig enn prosessoren: hvis det oppst\u00e5r ytelsesproblemer p\u00e5 VM-en, er det vanskelig \u00e5 ikke legge merke til dem. Men hvis de dukker opp, er det mye vanskeligere \u00e5 h\u00e5ndtere dem. Men la oss ta det steg for steg. <\/a><\/noindex><\/p>\n

Litt teori<\/h3>\n

\nRAM for virtuelle maskiner hentes fra serverens minne der VMer kj\u00f8rer. Dette er ganske \u00e5penbart :). Hvis serverens RAM ikke er tilstrekkelig for alle som \u00f8nsker det, begynner ESXi \u00e5 bruke teknikker for optimalisering av minneforbruk (memory reclamation techniques). Ellers ville operativsystemene til VM-ene krasjet med minneadgangsfeil. <\/p>\n

Hvilke teknikker ESXi bruker, bestemmes av belastningen p\u00e5 RAM:<\/p>\n

Minneforhold<\/b><\/p>\n

Grense<\/b><\/p>\n

Handlinger<\/b><\/p>\n

H\u00f8y<\/p>\n

400% av minFree<\/p>\n

N\u00e5r den \u00f8verste grensen er n\u00e5dd, deles store minnesider opp i sm\u00e5 (TPS fungerer i standardmodus).<\/p>\n

Clear<\/p>\n

100% av minFree<\/p>\n

Store minnesider deles opp i sm\u00e5, TPS kj\u00f8rer tvingende.<\/p>\n

Soft<\/p>\n

64% av minFree<\/p>\n

TPS + Ballong<\/p>\n

Hard<\/p>\n

32% av minFree<\/p>\n

TPS + Komprimering + Bytte<\/p>\n

Lav<\/p>\n

16% av minFree<\/p>\n

Komprimering + Bytte + Blokk<\/p>\n

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

minFree er det minnet som er n\u00f8dvendig for hypervisorens drift. <\/p>\n

Frem til og med ESXi 4.1 var minFree som standard fast \u2014 6% av serverens RAM (prosentandelen kunne endres via alternativet Mem.MinFreePct p\u00e5 ESXi). I nyere versjoner begynte minFree \u00e5 beregnes ut fra vertsmaskinens minnest\u00f8rrelse i stedet for som en fast prosentandel. <\/p>\n

MinFree-verdien (som standard) beregnes som f\u00f8lgende:<\/p>\n

Prosentandel av minnet reservert for minFree<\/b><\/p>\n

Minneomr\u00e5de<\/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

Gjenst\u00e5ende minne<\/p>\n

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

For eksempel, for en server med 128 GB RAM vil verdien av MinFree v\u00e6re:
\nMinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
\nDen faktiske verdien kan variere med et par hundre MB, avhengig av serveren og RAM-en.<\/p>\n

Prosentandel av minnet reservert for minFree<\/b><\/p>\n

Minneomr\u00e5de<\/b><\/p>\n

Verdi for 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

Gjenst\u00e5ende minne (100 GB)<\/p>\n

1024 MB<\/p>\n

\nNormalt anses kun High-tilstand som akseptabel for produktive milj\u00f8er. For test- og utviklingsmilj\u00f8er kan Clear\/Soft-tilstander v\u00e6re akseptable. Hvis det er mindre enn 64% av MinFree p\u00e5 vertsmaskinen, vil VM-ene som kj\u00f8rer p\u00e5 den, absolutt oppleve ytelsesproblemer.<\/p>\n

I hver tilstand anvendes bestemte memory reclamation techniques fra TPS, som praktisk talt ikke p\u00e5virker VM-ydelsen, til Swapping. Jeg vil forklare dem n\u00e6rmere. <\/p>\n

Transparent Page Sharing (TPS).<\/b> TPS er groft sagt deduplisering af RAM-siderne p\u00e5 virtuelle maskiner p\u00e5 serveren.<\/p>\n

ESXi s\u00f8ger efter identiske RAM-sider blandt de virtuelle maskiner ved at beregne og sammenligne hash-v\u00e6rdierne af siderne og fjerner dublikaterne ved at erstatte dem med henvisninger til den samme side i serverens fysiske hukommelse. Som resultat reduceres forbruget af fysisk hukommelse, og man kan opn\u00e5 en vis overskrivning af hukommelsen praktisk talt uden tabs i ydeevnen.<\/p>\n

\"Analyse
\nKilde<\/a><\/noindex><\/p>\n

Denne mekanisme fungerer kun for hukommelsessider af 4 KB (small pages). Hypervisoren fors\u00f8ger ikke engang at deduplicere 2 MB (large pages) sider: chancen for at finde identiske sider af den st\u00f8rrelse er ikke stor.<\/p>\n

Som standard tildeler ESXi hukommelse til de store sider. Opdeling af store sider til sm\u00e5 starter, n\u00e5r t\u00e6rskeltilstanden High n\u00e5s og sker tvangsvis, n\u00e5r Clear-tilstanden n\u00e5s (se hypervisorens tilstandstabel).<\/p>\n

Hvis du \u00f8nsker, at TPS skal starte arbejdet uden at vente p\u00e5, at v\u00e6rtens hukommelse fyldes, skal du indstille v\u00e6rdien \u201cMem.AllocGuestLargePage\u201d<\/i> til 0 (standard 1). S\u00e5 vil tildeling af store hukommelsessider til virtuelle maskiner blive deaktiveret.<\/p>\n

Fra december 2014 er TPS mellem VM'er som standard deaktiveret i alle ESXi-udgivelser, da der blev fundet en s\u00e5rbarhed, der teoretisk set kunne give adgang til RAM'en fra en VM til en anden. Yderligere information her. Jeg har ikke set oplysninger om praktisk udnyttelse af TPS-s\u00e5rbarheden.<\/p>\n

TPS-politikken styres via den avancerede mulighed \u201cMem.ShareForceSalting\u201d<\/i> p\u00e5 ESXi:
\n0 \u2014 Inter-VM TPS. TPS arbejder p\u00e5 sider mellem forskellige VM'er;
\n1 \u2013 TPS for VM'er med samme v\u00e6rdi for \u201csched.mem.pshare.salt\u201d i VMX;
\n2 (standard) \u2013 Intra-VM TPS. TPS arbejder p\u00e5 sider inden for VM.<\/p>\n

Det giver bestemt mening at deaktivere store sider og aktivere Inter-VM TPS p\u00e5 testmilj\u00f8er. Dette kan ogs\u00e5 bruges til milj\u00f8er med mange ensartede VM'er. For eksempel kan besparelsen af fysisk hukommelse p\u00e5 VDI-milj\u00f8er n\u00e5 op p\u00e5 titusinder af procent. <\/p>\n

Memory Ballooning.<\/b> Ballooning er ikke lenger s\u00e5 ufarlig og gjennomsiktig for operativsystemet som VM-teknikken TPS. Men med riktig bruk av Ballooning kan man leve med det og til og med jobbe.<\/p>\n

Sammen med Vmware Tools installeres en spesiell driver p\u00e5 VM-en, kalt Balloon Driver (ogs\u00e5 kjent som vmmemctl). N\u00e5r hypervisoren begynner \u00e5 mangle fysisk minne og g\u00e5r over i tilstanden Soft, ber ESXi VM-en om \u00e5 returnere ubrukt RAM via denne Balloon Driveren. Driveren jobber i sin tur p\u00e5 niv\u00e5et til operativsystemet og ber om ledig minne derfra. Hypervisoren ser hvilke sider av den fysiske minne som er opptatt av Balloon Driver, tar minnet fra den virtuelle maskinen og returnerer det til verten. Det oppst\u00e5r ingen problemer med driften av OS, da minnet p\u00e5 OS-niv\u00e5 er okkupert av Balloon Driver. Som standard kan Balloon Driver ta opptil 65% av minnet til VM-en.<\/p>\n

Hvis VMware Tools ikke er installert p\u00e5 VM-en eller Ballooning er deaktivert (jeg anbefaler ikke dette, men det er KB<\/a><\/noindex>:), g\u00e5r hypervisoren umiddelbart over til mer aggressive teknikker for minnetrekk. Konklusjon: S\u00f8rg for at VMware Tools er installert p\u00e5 VM-en.<\/p>\n

\"Analyse
\nFunksjonen til Balloon Driver kan sjekkes fra OS via VMware Tools.<\/i>.<\/p>\n

Memory Compression.<\/b> Denne teknikken brukes n\u00e5r ESXi n\u00e5r Hard-tilstanden. Som navnet antyder, pr\u00f8ver ESXi \u00e5 komprimere 4 KB sider av RAM til 2 KB og dermed frigj\u00f8re litt plass i den fysiske minnen til serveren. Denne teknikken \u00f8ker betydelig tilgangen til innholdet i RAM-sidene til VM-en, da siden m\u00e5 dekomprimeres f\u00f8rst. Noen ganger klarer man ikke \u00e5 komprimere alle sidene, og selve prosessen tar litt tid. Derfor er denne teknikken ikke veldig effektiv i praksis.<\/p>\n

Memory Swapping.<\/b> Etter en kort fase med Memory Compression, g\u00e5r ESXi nesten uunng\u00e5elig (hvis VM-ene ikke har flyttet til andre verter eller skrudd av) over til Swapping. Og hvis det er veldig lite minne igjen (Low-tilstand), slutter hypervisoren ogs\u00e5 \u00e5 tildele VM-sider med minne, noe som kan for\u00e5rsake problemer i gjeste-OSene til VM-en.<\/p>\n

Slik fungerer Swapping. N\u00e5r en virtuell maskin startes, opprettes en fil med .vswp-utvidelse for den. St\u00f8rrelsen er lik den ikke-reserverte RAM-en til VM-en: det er forskjellen mellom konfigurert og reserverte minne. N\u00e5r Swapping er aktivert, overf\u00f8rer ESXi minnesider fra den virtuelle maskinen til denne filen og begynner \u00e5 jobbe med den i stedet for den fysiske minnen p\u00e5 serveren. Selvf\u00f8lgelig er denne 'minnen' flere st\u00f8rrelsesordener tregere enn faktisk minne, selv om .vswp ligger p\u00e5 rask lagring.<\/p>\n

I motsetning til Ballooning, hvor VM-en mister ubrukte sider, kan ved Swapping sider som aktivt brukes av operativsystemet eller applikasjoner i VM-en flyttes til disk. Som et resultat faller ytelsen til VM-en, opp til hengning. VM-en fungerer formelt og kan i det minste riktig stenges fra OS. Hvis du er t\u00e5lmodig \ud83d\ude09<\/p>\n

Hvis VM-ene har g\u00e5tt i Swap, er det en unormal situasjon som best unng\u00e5s.<\/p>\n

Hovedytelsesm\u00e5lere for minnet til den virtuelle maskinen<\/h3>\n

\nN\u00e5 har vi n\u00e5dd kjernen av saken. For \u00e5 overv\u00e5ke minnestatusen i VM-en finnes f\u00f8lgende m\u00e5lere:<\/p>\n

Aktiv<\/b> \u2014 viser mengden RAM (KB) som VM-en hadde tilgang til i den forrige m\u00e5leperioden.<\/p>\n

Bruk<\/b> \u2014 det samme som Aktive, men i prosent av den konfigurerte RAM-en til VM-en. Beregnes med f\u00f8lgende formel: aktiv \u00f7 virtual machine configured memory size.
\nH\u00f8y Bruk og Aktiv betyr ikke n\u00f8dvendigvis at det er ytelsesproblemer med VM-en. Hvis VM-en aggressivt bruker minne (minst f\u00e5r tilgang til det), betyr det ikke at det er mangel p\u00e5 minne. Snarere er det en grunn til \u00e5 se p\u00e5 hva som skjer i OS.
\nDet finnes en standard Alarm for Memory Usage for VM-er:<\/p>\n

\"Analyse
\n
\nDelt<\/b> \u2014 volumet av RAM i VM-en som er deduplisert ved hjelp av TPS (internt i VM-en eller mellom VM-er).<\/p>\n

Tildelt<\/b> \u2014 volumet av fysisk minne p\u00e5 verten (KB) som er tildelt til VM-en. Inkluderer Delt.<\/p>\n

Brukt<\/b> (Tildelt \u2014 Delt) \u2014 volumet av fysisk minne (KB) som VM-en bruker fra verten. Inkluderer ikke Delt.<\/p>\n

Hvis en del av minnet til VM-en tildeles fra swap-filen eller minne er avsk\u00e5ret fra VM-en via Balloon Driver, blir dette ikke inkludert i Tildelt og Brukt.
\nH\u00f8ye verdier for Granted og Consumed er helt normalt. Operativsystemet tar gradvis minne fra hypervisoren og gir det ikke tilbake. Over tid n\u00e6rmer dataene til disse tellerne seg volumet av den konfigurerte minnen, og de forblir der.<\/p>\n

Null<\/b> \u2014 volumet av VM RAM (Kbyte) som inneholder nuller. Slikt minne betraktes som ledig av hypervisoren og kan gis til andre virtuelle maskiner. Etter at gjeste-OS har skrevet noe i det nullstilte minnet, m\u00e5 det over til Consumed og kommer ikke tilbake.<\/p>\n

Reserved Overhead<\/b> \u2014 volumet av VM RAM (Kbyte) som er reservert av hypervisoren for \u00e5 f\u00e5 VM til \u00e5 fungere. Dette er et lite volum, men det m\u00e5 absolutt v\u00e6re tilgjengelig p\u00e5 verten, ellers kan ikke VM starte.<\/p>\n

Balloon<\/b> \u2014 volumet av RAM (Kbyte) som er tatt fra VM ved hjelp av Balloon Driver.<\/p>\n

Compressed<\/b> \u2014 volumet av RAM (Kbyte) som har blitt komprimert.<\/p>\n

Swapped<\/b> \u2014 volumet av RAM (Kbyte) som, p\u00e5 grunn av mangel p\u00e5 fysisk minne p\u00e5 serveren, har flyttet til disken.
\nBalloon og andre tellere for minnegjenvinning er lik null.<\/p>\n

Slik ser grafen med telere for en normalt fungerende VM med 150 GB RAM ut.<\/p>\n

\"Analyse
\n
\nGrafen nedenfor viser tydelige problemer for VM. Under grafen kan vi se at alle beskrevne teknikker for minnebehandling har blitt brukt for denne VM. Balloon for denne VM er betydelig st\u00f8rre enn Consumed. Faktisk er VM mer d\u00f8d enn levende. <\/p>\n

\"Analyse
\n<\/p>\n

ESXTOP<\/h3>\n

\nSom med CPU, hvis vi vil vurdere situasjonen p\u00e5 verten raskt, samt dens dynamikk med intervaller p\u00e5 opptil 2 sekunder, er det best \u00e5 bruke ESXTOP.<\/p>\n

ESXTOP-skjermen for minne aktiveres med 'm'-tasten og ser slik ut (feltene B,D,H,J,K,L,O er valgt):<\/p>\n

\"Analyse
\n
\nF\u00f8lgende parametere vil v\u00e6re interessante for oss: <\/p>\n

Mem overcommit avg<\/b> \u2014 gjennomsnittlig minneoverbooking p\u00e5 verten over 1, 5 og 15 minutter. Hvis det er over null, er det grunn til \u00e5 se hva som skjer, men det er ikke alltid et tegn p\u00e5 problemer.<\/p>\n

I linjene PMEM\/MB<\/b> og VMKMEM\/MB<\/b> \u2014 informasjon om den fysiske minnen til serveren og minnet tilgjengelig for VMkernel. Her kan vi se minfree-verdien (i MB), tilstanden til verten med hensyn til minne (i v\u00e5rt tilfelle, h\u00f8y).<\/p>\n

I linjen NUMA\/MB<\/b> kan vi se fordelingen av RAM over NUMA-noder (prosessorer). I dette eksempelet er fordelingen ujevn, noe som i prinsippet ikke er s\u00e5 bra.<\/p>\n

Her kjem generell statistikk om serveren vedr\u00f8rende minnegjenvinningsteknikker:<\/p>\n

PSHARE\/MB<\/b> \u2014 dette er TPS-statistikk;<\/p>\n

SWAP\/MB<\/b> \u2014 statistikk for bruk av Swap;<\/p>\n

ZIP\/MB<\/b> \u2014 statistikk for komprimering av minnesider;<\/p>\n

MEMCTL\/MB<\/b> \u2014 statistikk for bruk av Balloon Driver.<\/p>\n

For individuelle VM-er kan vi v\u00e6re interessert i f\u00f8lgende informasjon. Jeg har skjult VM-navnene for ikke \u00e5 forvirre publikum :). Hvis ESXTOP-metrikken er lik telleren i vSphere, gir jeg den tilsvarende telleren. <\/p>\n

MEMSZ<\/b> \u2014 mengden minne konfigurert p\u00e5 VM (MB).
\nMEMSZ = GRANT + MCTLSZ + SWCUR + untouched.<\/p>\n

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

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

MCTL?<\/b> \u2014 er Balloon Driver installert p\u00e5 VM.<\/p>\n

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

MCTLGT<\/b> \u2014 mengden RAM (MB) som ESXi \u00f8nsker \u00e5 trekke fra VM gjennom Balloon Driver (Memctl Target).<\/p>\n

MCTLMAX<\/b> \u2014 maks mengde RAM (MB) som ESXi kan trekke fra VM gjennom Balloon Driver.<\/p>\n

SWCUR<\/b> \u2014 n\u00e5v\u00e6rende mengde RAM (MB) tildelt VM fra Swap-filen. <\/p>\n

SWGT<\/b> \u2014 mengden RAM (MB) som ESXi \u00f8nsker \u00e5 gi VM fra Swap-filen (Swap Target).<\/p>\n

Gjennom ESXTOP kan man ogs\u00e5 se mer detaljert informasjon om NUMA-topologien til VM. For dette m\u00e5 man velge feltene D,G:<\/p>\n

\"Analyse
\n
\nNHN<\/b> \u2013 NUMA-noder der VM er plassert. Her kan man umiddelbart merke wide VM-er som ikke passer inn p\u00e5 \u00e9n NUMA-node.<\/p>\n

NRMEM<\/b> \u2013 hvor mange megabyte minne VM tar fra en fjern NUMA-node.<\/p>\n

NLMEM<\/b> \u2013 hvor mange megabyte minne VM tar fra en lokal NUMA-node.<\/p>\n

N%L<\/b> \u2013 prosent av minnet til VM p\u00e5 lokal NUMA-node (hvis under 80 % \u2014 kan det oppst\u00e5 ytelsesproblemer).<\/p>\n

Minne p\u00e5 hypervisoren<\/h3>\n

\nHvis CPU-tellere p\u00e5 hypervisoren vanligvis ikke er av stor interesse, er situasjonen med minnet den motsatte. H\u00f8y minnebruk p\u00e5 VM indikerer ikke alltid et ytelsesproblem, men h\u00f8y minnebruk p\u00e5 hypervisoren utl\u00f8ser faktisk minneh\u00e5ndteringsteknikker og for\u00e5rsaker problemer med ytelsen til VM. Man m\u00e5 overv\u00e5ke varslene for Host Memory Usage og unng\u00e5 at VM havner i Swap.<\/p>\n

\"Analyse
\n
\n\"Analyse
\n<\/p>\n

Unswap<\/h3>\n

\nHvis VM har havnet i Swap, vil ytelsen dens bli kraftig redusert. Spor av Ballooning og komprimering forsvinner raskt etter at det blir ledig RAM p\u00e5 verten, men det er ikke hastverk med \u00e5 komme seg fra Swap tilbake til serverens RAM.
\nFrem til ESXi 6.0 var den eneste p\u00e5litelige og hurtige m\u00e5ten \u00e5 hente VM fra Swap p\u00e5 \u00e5 starte den p\u00e5 nytt (mer presist \u00e5 skru av\/p\u00e5 containeren). Fra og med ESXi 6.0 ble det introdusert en metode som, selv om den ikke helt er offisiell, er en fungerende og p\u00e5litelig m\u00e5te \u00e5 hente VM fra Swap. P\u00e5 en av konferansene klarte jeg \u00e5 snakke med en av ingeni\u00f8rene i VMware som jobber med CPU Scheduler. Han bekreftet at metoden er fullt funksjonell og sikker. Vi har heller ikke hatt noen problemer med den i v\u00e5r erfaring.<\/p>\n

Kommandos for \u00e5 hente VM fra Swap beskrevet<\/a><\/noindex> Duncan Epping. Jeg vil ikke gjenta den detaljerte beskrivelsen, bare gi et eksempel p\u00e5 bruken av den. Som vist p\u00e5 skjermen, forsvinner Swap fra VM etter en tid etter at den angitte kommandoen er utf\u00f8rt.<\/p>\n

\"Analyse
\n<\/p>\n

Tips for \u00e5 h\u00e5ndtere RAM p\u00e5 ESXi<\/h3>\n

\nTil slutt gir jeg noen tips som kan hjelpe deg med \u00e5 unng\u00e5 ytelsesproblemer i VM p\u00e5 grunn av RAM:<\/p>\n