Tässä artikkelissa puhumme vSpheren hajasaantimuistin (RAM) suorituskykylaskureista.
Näyttää siltä, että muistilla kaikki on selkeämpää kuin prosessorilla: jos virtuaalikoneella on suorituskykyongelmia, niitä on vaikea olla huomaamatta. Mutta jos ne ilmestyvät, on paljon vaikeampaa käsitellä niitä. Mutta ensin asiat ensin.
Hieman teoria
Virtuaalikoneiden RAM otetaan sen palvelimen muistista, jossa VM:t ovat käynnissä. Se on aika selvää :). Jos palvelimen RAM ei riitä kaikille, ESXi alkaa käyttää muistin palautustekniikoita RAM-muistin kulutuksen optimoimiseksi. Muuten VM-käyttöjärjestelmät kaatuisivat RAM-käyttövirheiden vuoksi.
Mitä ESXi-tekniikoita käytetään, riippuu RAM-muistin kuormituksesta:
Muististatus
reunus
Aktiivisuus
Korkea
400% minFreestä
Kun yläraja on saavutettu, suuret muistisivut jaetaan pieniksi (TPS toimii vakiotilassa).
Poista valinta
100% minFreestä
Suuret muistisivut hajotetaan pieniksi, TPS pakotetaan toimimaan.
Pehmeä
64% minFreestä
TPS + ilmapallo
Kova
32% minFreestä
TPS + pakkaus + vaihto
Matala
16% minFreestä
Pakkaa + Vaihda + Estä
minFree on RAM-muisti, joka tarvitaan hypervisorin toimimiseen.
Ennen ESXi 4.1:tä minFree oli oletusarvoisesti kiinteä - 6% palvelimen RAM-muistista (prosenttia voitiin muuttaa ESXi:n Mem.MinFreePct-vaihtoehdolla). Myöhemmissä versioissa palvelimien muistin koon kasvun vuoksi minFree alkoi laskea isäntämuistin määrän perusteella, ei kiinteänä prosenttiosuutena.
MinFree-arvo (oletusarvo) lasketaan seuraavasti:
MinFreelle varatun muistin prosenttiosuus
Muistialue
6%
0-4 Gt
4%
4-12 Gt
2%
12-28 Gt
1%
Jäljellä oleva muisti
Esimerkiksi palvelimelle, jossa on 128 Gt RAM-muistia, MinFree-arvo olisi:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 Mt = 1,88 Gt
Todellinen arvo voi vaihdella pari sataa Mt, se riippuu palvelimesta ja RAM-muistista.
MinFreelle varatun muistin prosenttiosuus
Muistialue
Arvo 128 Gt
6%
0-4 Gt
245,76 Mt
4%
4-12 Gt
327,68 Mt
2%
12-28 Gt
327,68 Mt
1%
Jäljellä oleva muisti (100 Gt)
1024 Mt
Yleensä tuottavien metsien osalta vain High-tilaa voidaan pitää normaalina. Testi- ja kehityspenkeissä Clear/Soft-tilat voivat olla hyväksyttäviä. Jos isännän RAM-muistin MinFree on alle 64 %, siinä käytävissä virtuaalikoneissa on varmasti suorituskykyongelmia.
Kussakin tilassa käytetään tiettyjä muistin palautustekniikoita alkaen TPS:stä, joka ei käytännössä vaikuta VM:n suorituskykyyn, ja päättyen vaihtoon. Kerron niistä lisää.
Transparent Page Sharing (TPS). TPS on karkeasti sanottuna virtuaalikoneen muistisivujen duplikoinnin poistamista palvelimella.
ESXi etsii identtisiä sivuja virtuaalikoneen RAM-muistista laskemalla ja vertaamalla sivujen hash-summaa ja poistaa päällekkäiset sivut korvaamalla ne linkeillä samalle sivulle palvelimen fyysisessä muistissa. Tämän seurauksena fyysisen muistin kulutus vähenee ja jonkin verran muistin ylitilausta voidaan saavuttaa ilman, että suorituskyky heikkenee vain vähän tai ei ollenkaan.
Tämä mekanismi toimii vain 4 kt:n muistisivuilla (pienillä sivuilla). Hypervisor ei edes yritä poistaa kopioita 2 Mt:n sivuista (isot sivut): mahdollisuus löytää tämän kokoisia identtisiä sivuja ei ole suuri.
Oletusarvoisesti ESXi varaa muistia suurille sivuille. Suurten sivujen jakaminen pieniksi sivuiksi alkaa, kun korkean tilan kynnys saavutetaan, ja pakotetaan, kun Tyhjennä-tila saavutetaan (katso hypervisorin tilataulukko).
Jos haluat, että TPS alkaa toimia odottamatta isäntämuistin täyttymistä, Advanced Options ESXi:ssä sinun on asetettava arvo "Mem.AllocGuestLargePage" arvoon 0 (oletus 1). Sitten suurten muistisivujen varaaminen virtuaalikoneita varten poistetaan käytöstä.
Joulukuusta 2014 lähtien kaikissa ESXi-julkaisuissa virtuaalikoneiden välinen TPS on oletusarvoisesti poistettu käytöstä, koska havaittiin haavoittuvuus, joka teoriassa sallii pääsyn yhdestä VM:stä toisen virtuaalikoneen RAM-muistiin. Yksityiskohdat täältä. En ole törmännyt tietoon TPS-haavoittuvuuden hyödyntämisen käytännön toteutuksesta.
TPS-käytäntöä ohjataan lisätoiminnolla "Mem.ShareForceSalting" ESXi:ssä:
0 - Inter-VM TPS. TPS toimii eri virtuaalikoneiden sivuilla;
1 – TPS VM:lle samalla "sched.mem.pshare.salt"-arvolla VMX:ssä;
2 (oletus) - VM:n sisäinen TPS. TPS toimii VM:n sisäisillä sivuilla.
On ehdottomasti järkevää sammuttaa suuret sivut ja ottaa käyttöön Inter-VM TPS testipenkeillä. Sitä voidaan käyttää myös telineissä, joissa on suuri määrä samantyyppisiä VM-laitteita. Esimerkiksi telineissä, joissa on VDI, fyysisen muistin säästö voi olla kymmeniä prosentteja.
muistin ilmapalloilu. Ballooning ei ole enää niin vaaraton ja läpinäkyvä tekniikka VM-käyttöjärjestelmälle kuin TPS. Mutta oikealla sovelluksella voit elää ja jopa työskennellä Ballooningin kanssa.
Yhdessä Vmware Toolsin kanssa virtuaalikoneeseen asennetaan erityinen ohjain nimeltä Balloon Driver (alias vmmemctl). Kun hypervisorin fyysinen muisti alkaa loppua ja se siirtyy pehmeään tilaan, ESXi pyytää virtuaalikonetta ottamaan takaisin käyttämättömän RAM-muistin tämän Balloon Driver -ohjaimen kautta. Ohjain puolestaan toimii käyttöjärjestelmätasolla ja pyytää siltä vapaata muistia. Hypervisor näkee, mitkä fyysisen muistin sivut Balloon Driver on varannut, ottaa muistin virtuaalikoneen ja palauttaa sen isännälle. Käyttöjärjestelmän toiminnassa ei ole ongelmia, koska käyttöjärjestelmätasolla muisti on Balloon Driver -ajurin käytössä. Oletuksena Balloon Driver voi viedä jopa 65 % VM-muistista.
Jos VMware Toolsia ei ole asennettu virtuaalikoneen tai Ballooning on poistettu käytöstä (en suosittele, mutta on olemassa :), hypervisor vaihtaa välittömästi tiukempiin muistinpoistotekniikoihin. Johtopäätös: varmista, että VMware-työkalut ovat VM:ssä.
Balloon Driverin toiminta voidaan tarkistaa käyttöjärjestelmästä VMware Toolsin kautta.
muistin pakkaus. Tätä tekniikkaa käytetään, kun ESXi saavuttaa kovan tilan. Kuten nimestä voi päätellä, ESXi yrittää kutistaa 4 kt:n sivun RAM-muistia 2 kt:ksi ja vapauttaa siten tilaa palvelimen fyysisessä muistissa. Tämä tekniikka pidentää merkittävästi VM RAM -sivujen sisällön käyttöaikaa, koska sivu on ensin purettava. Joskus kaikkia sivuja ei voida pakata ja itse prosessi kestää jonkin aikaa. Siksi tämä tekniikka ei ole kovin tehokas käytännössä.
muistin vaihto. Lyhyen muistin pakkausvaiheen jälkeen ESXi siirtyy melkein väistämättä (jos virtuaalikoneet eivät ole lähteneet muille isännille tai sammuneet) vaihtamiseen. Ja jos muistia on jäljellä hyvin vähän (Low-tila), hypervisor lopettaa myös muistisivujen varaamisen VM:lle, mikä voi aiheuttaa ongelmia virtuaalikoneen vieraskäyttöjärjestelmässä.
Näin vaihto toimii. Kun käynnistät virtuaalikoneen, sille luodaan tiedosto, jonka laajennus on .vswp. Se on kooltaan yhtä suuri kuin VM:n varaamaton RAM: se on ero konfiguroidun ja varatun muistin välillä. Kun Swapping on käynnissä, ESXi purkaa virtuaalikoneen muistisivut tähän tiedostoon ja alkaa työskennellä sen kanssa palvelimen fyysisen muistin sijaan. Tietenkin tällainen "toiminnallinen" muisti on useita suuruusluokkia hitaampi kuin todellinen, vaikka .vswp on nopealla tallennustilalla.
Toisin kuin Ballooning, kun käyttämättömät sivut otetaan VM:stä, sivut, joita käyttöjärjestelmä tai VM:n sisällä olevat sovellukset käyttävät aktiivisesti, voivat siirtyä levylle. Tämän seurauksena VM:n suorituskyky laskee jäätymispisteeseen asti. VM toimii muodollisesti ja ainakin se voidaan poistaa kunnolla käytöstä käyttöjärjestelmästä. Jos olet kärsivällinen 😉
Jos virtuaalikoneet siirtyivät Swapiin, tämä on epänormaali tilanne, joka on parasta välttää, jos mahdollista.
Keskeiset VM-muistin suorituskykylaskurit
Pääsimme siis pääasiaan. VM:n muistin tilan seurantaa varten on seuraavat laskurit:
Aktiiviset — näyttää RAM-muistin määrän (KB), johon VM sai pääsyn edellisellä mittausjaksolla.
Käyttö - sama kuin Active, mutta prosentteina virtuaalikoneen konfiguroidusta RAM-muistista. Lasketaan seuraavalla kaavalla: aktiivinen ÷ virtuaalikoneen määritetty muistin koko.
High Usage ja Active, vastaavasti, eivät aina osoita virtuaalikoneen suorituskykyongelmia. Jos virtuaalikone käyttää aggressiivisesti muistia (ainakin saa pääsyn siihen), tämä ei tarkoita, että muisti ei riitä. Pikemminkin se on tilaisuus nähdä, mitä käyttöjärjestelmässä tapahtuu.
Virtuaalisille koneille on vakiomuistin käyttöhälytys:
Yhteinen - TPS:n avulla (VM:n sisällä tai VM:ien välillä) duplikoidun VM-RAM-muistin määrä.
myönnetty - VM:lle annettu fyysisen isäntämuistin määrä (KB). Sisältää jaetun.
Consumed (Myönnetty - Jaettu) - fyysisen muistin määrä (KB), jonka VM kuluttaa isännästä. Ei sisällä Jaettua.
Jos osa VM-muistista ei ole annettu isäntäkoneen fyysisestä muistista, vaan swap-tiedostosta tai muisti otetaan VM:stä Balloon Driver -ajurin kautta, tätä määrää ei oteta huomioon Myönnetty ja kulutettu -kohdassa.
Korkeat myönnetyt ja kulutetut arvot ovat täysin normaaleja. Käyttöjärjestelmä ottaa vähitellen muistia hypervisorilta eikä anna sitä takaisin. Ajan myötä aktiivisesti käynnissä olevassa virtuaalikoneessa näiden laskurien arvot lähestyvät määritetyn muistin määrää ja pysyvät siellä.
nolla — VM RAM:n määrä (KB), joka sisältää nollia. Hypervisor pitää tällaista muistia vapaana, ja se voidaan antaa muille virtuaalikoneen. Kun vieraskäyttöjärjestelmä on kirjoittanut jotain nollattuun muistiin, se siirtyy Consumed-tilaan eikä palaa takaisin.
Varattu Overhead — VM-RAM-muistin määrä (KB), jonka hypervisor on varannut VM-toimintaa varten. Tämä on pieni määrä, mutta sen on oltava saatavilla isännässä, muuten virtuaalikone ei käynnisty.
Ilmapallo — RAM-muistin määrä (KB), joka on takavarikoitu virtuaalikoneesta Balloon Driver -ajurin avulla.
Tiivistetty - pakatun RAM-muistin määrä (KB).
vaihtoivat - RAM-muistin määrä (KB), joka palvelimen fyysisen muistin puutteen vuoksi siirrettiin levylle.
Ilmapallojen ja muiden muistin palautustekniikoiden laskurit ovat nolla.
Tältä kaavio muistilaskureineen näyttää normaalisti toimivalle VM:lle, jossa on 150 Gt RAM-muistia.
Alla olevassa kaaviossa VM:llä on ilmeisiä ongelmia. Kaavion alta näet, että tässä VM:ssä käytettiin kaikkia kuvattuja tekniikoita RAM-työskentelyyn. Tämän virtuaalikoneen ilmapallo on paljon suurempi kuin Consumed. Itse asiassa VM on enemmän kuollut kuin elossa.
ESXTOP
Kuten CPU:ssa, jos haluamme nopeasti arvioida isännän tilannetta ja sen dynamiikkaa jopa 2 sekunnin välein, meidän tulisi käyttää ESXTOP:ia.
Muistin ESXTOP-näyttö avautuu "m"-näppäimellä ja näyttää tältä (kentät B, D, H, J, K, L, O on valittu):
Seuraavat parametrit kiinnostavat meitä:
Muisti ylisitoutumisen keskim - isäntäkoneen muistin ylitilauksen keskimääräinen arvo 1, 5 ja 15 minuutiksi. Jos se on nollan yläpuolella, tämä on tilaisuus nähdä, mitä tapahtuu, mutta ei aina osoitus ongelmista.
Linjoissa PMEM/MB и VMKMEM/MB - tiedot palvelimen fyysisestä muistista ja VMkernelin käytettävissä olevasta muistista. Tästä mielenkiintoisesta voit nähdä minfree-arvon (Mt), isännän tilan muistissa (tapauksessamme korkea).
Linjassa NUMA/MB voit nähdä RAM-jakauman NUMA-solmujen (sockettien) mukaan. Tässä esimerkissä jakauma on epätasainen, mikä ei periaatteessa ole kovin hyvä.
Seuraavassa on yleiset palvelintilastot muistin palautustekniikoista:
PSHARE/MB ovat TPS-tilastot;
SWAP/MB — Swap-käyttötilastot;
ZIP/MB — muistisivujen pakkaustilastot;
MEMCTL/MB — Balloon Driver -käyttötilastot.
Yksittäisten virtuaalikoneiden osalta saatamme olla kiinnostuneita seuraavista tiedoista. Piilotin VM-nimet, jotta en hämmennä yleisöä :). Jos ESXTOP-mittari on samanlainen kuin vSpheren laskuri, annan vastaavan laskurin.
MEMSZ — VM:lle määritetyn muistin määrä (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + koskematon.
MYÖNTÄÄ — Myönnetty MB:lle.
TCHD — Aktiivinen MB.
MCTL? - onko Balloon Driver asennettu virtuaalikoneeseen.
MCTLSZ — Ilmapallo MB:lle.
MCTLGT — RAM-muistin määrä (MB), jonka ESXi haluaa ottaa VM:ltä Balloon Driverin (Memctl Target) kautta.
MCTLMAX - enimmäismäärä RAM-muistia (MB), jonka ESXi voi ottaa VM:ltä Balloon Driver -ohjaimen kautta.
SWCUR — VM:lle Swap-tiedostosta varatun nykyisen RAM-muistin määrä (MB).
S.W.G.T. - RAM-muistin määrä (MB), jonka ESXi haluaa antaa VM:lle Swap-tiedostosta (Swap Target).
ESXTOP:n kautta näet myös tarkempia tietoja VM:n NUMA-topologiasta. Voit tehdä tämän valitsemalla kentät D, G:
PIENI – NUMA-solmuja, joissa virtuaalikone sijaitsee. Tässä huomaa heti leveät vm:t, jotka eivät mahdu yhteen NUMA-solmuun.
NRMEM - kuinka monta megatavua muistia VM vie NUMA-etäsolmulta.
NLMEM - kuinka monta megatavua muistia VM vie paikalliselta NUMA-solmulta.
N%L – VM-muistin prosenttiosuus paikallisessa NUMA-solmussa (jos alle 80 %, suorituskykyongelmia voi ilmetä).
Muisti hypervisorissa
Jos hypervisorin CPU-laskurit eivät yleensä ole erityisen kiinnostavia, tilanne on päinvastainen muistin kanssa. VM:n suuri muistin käyttö ei aina tarkoita suorituskykyongelmaa, mutta hypervisorin suuri muistin käyttö laukaisee muistinhallintatekniikoita ja aiheuttaa suorituskykyongelmia virtuaalikoneessa. Isäntämuistin käyttöhälytyksiä on valvottava, jotta virtuaalikonetta ei pääse Swapiin.
Poista vaihto
Jos VM on Swap-tilassa, sen suorituskyky heikkenee huomattavasti. Ballooning- ja pakkausjäljet katoavat nopeasti, kun vapaa RAM-muisti ilmestyy isäntään, mutta virtuaalikoneella ei ole kiirettä palata Swapista palvelimen RAM-muistiin.
Ennen ESXi 6.0:aa ainoa luotettava ja nopea tapa saada VM pois Swapista oli käynnistää uudelleen (tarkemmin sanottuna kontin sammuttaminen/päälle). ESXi 6.0:sta alkaen, vaikkakaan ei aivan virallisesti, on ilmestynyt toimiva ja luotettava tapa poistaa VM Swapista. Yhdessä konferenssissa pystyin puhumaan yhden CPU Schedulerista vastaavan VMware-insinöörin kanssa. Hän vahvisti, että menetelmä on varsin toimiva ja turvallinen. Kokemuksemme mukaan siinäkään ei ollut ongelmia.
Varsinaiset komennot VM:n poistamiseksi Swapista Duncan Epping. En toista yksityiskohtaista kuvausta, anna vain esimerkki sen käytöstä. Kuten kuvakaappauksesta näkyy, Swap katoaa virtuaalikoneelta jonkin aikaa määritettyjen komentojen suorittamisen jälkeen.
ESXi-muistinhallintavinkkejä
Lopuksi tässä on joitain vinkkejä, jotka auttavat sinua välttämään RAM-muistista johtuvia VM-suorituskykyongelmia:
- Vältä muistin ylitilauksia tuottavissa klustereissa. On toivottavaa, että klusterissa on aina ~20-30% vapaata muistia, jotta DRS:llä (ja järjestelmänvalvojalla) on liikkumavaraa, eivätkä VM:t mene Swapiin siirron aikana. Älä myöskään unohda vikasietomarginaalia. On epämiellyttävää, kun yksi palvelin epäonnistuu ja VM käynnistetään uudelleen HA:lla, osa koneista menee myös Swapiin.
- ÄLÄ yritä luoda erittäin konsolidoiduissa infrastruktuureissa virtuaalikoneita, joissa on yli puolet isäntämuistista. Tämä taas auttaa DRS:ää jakamaan virtuaalikoneita klusteripalvelimien kesken ilman ongelmia. Tämä sääntö ei tietenkään ole yleinen :).
- Varo isännän muistin käyttöhälytystä.
- Älä unohda asentaa VMware Toolsia virtuaalikoneeseen äläkä sammuta Ballooningia.
- Harkitse Inter-VM TPS:n ottamista käyttöön ja Large Pages -sovelluksen poistamista käytöstä VDI- ja testiympäristöissä.
- Jos virtuaalikoneessa on suorituskykyongelmia, tarkista, käyttääkö se muistia NUMA-etäsolmusta.
- Poista VM:si Swapista mahdollisimman nopeasti! Muun muassa, jos VM on Swap-tilassa, ilmeisistä syistä kärsii tallennusjärjestelmä.
Siinä kaikki minulle RAM-muistista. Alla on aiheeseen liittyvä artikkeli niille, jotka haluavat kaivaa yksityiskohtiin. Seuraava artikkeli on omistettu storadzhille.
Hyödyllisiä linkkejä
Lähde: will.com