I denna artikel kommer vi att prata om prestandaövervakningsrÀknare för RAM i vSphere.
Det verkar som att minnet Àr mer entydigt Àn processorn: om det uppstÄr prestandaproblem pÄ VM Àr det svÄrt att inte mÀrka dem. Men nÀr de vÀl dyker upp Àr det mycket svÄrare att hantera dem. Men vi tar det steg för steg.
Lite teori
RAM-minnet för virtuella maskiner tas frÄn serverns minne dÀr VMen körs. Detta Àr ganska uppenbart :). Om serverns RAM inte rÀcker till alla som vill anvÀnda det, börjar ESXi att anvÀnda minnesÄtervinningstekniker. Annars skulle operativsystemen för VMen krascha med minnesaccessfel.
Vilka tekniker ESXi ska anvÀnda avgörs av belastningen pÄ RAM:
MinnestillstÄnd
GrÀns
à tgÀrder
Hög
400% av minFree
NÀr den övre grÀnsen nÄs, delas stora minnessidor upp i smÄ (TPS fungerar i standardlÀge).
Rensa
100% av minFree
Stora minnessidor delas upp i smÄ, TPS fungerar tvingat.
Mjuk
64% av minFree
TPS + Ballong
HĂ„rd
32% av minFree
TPS + Komprimera + Byte
LĂ„g
16% av minFree
Komprimera + Byte + Blockera
minFree Àr det RAM-minne som behövs för att hypervisor ska fungera.
Fram till och med ESXi 4.1 var minFree som standard fixerat â 6% av serverns RAM-kapacitet (procentsatsen kunde Ă€ndras via alternativet Mem.MinFreePct i ESXi). I senare versioner, pĂ„ grund av ökade minnesmĂ€ngder pĂ„ servrar, började minFree berĂ€knas utifrĂ„n hostens minneskapacitet snarare Ă€n som en fast procentsats.
VÀrdet för minFree (som standard) berÀknas pÄ följande sÀtt:
Procentsats av minnet som reserveras för minFree
MinnesomrÄde
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
à terstÄende minne
Till exempel, för en server med 128 GB RAM blir vÀrdet för MinFree sÄ hÀr:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Det faktiska vÀrdet kan skilja sig med nÄgra hundra MB, detta beror pÄ servern och RAM-minnet.
Procentsats av minnet som reserveras för minFree
MinnesomrÄde
VÀrdet för 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
à terstÄende minne (100 GB)
1024 MB
Vanligtvis kan endast tillstÄndet High betraktas som normalt för produktionsmiljöer. För test- och utvecklingsmiljöer kan tillstÄnd som Clear/Soft vara acceptabla. Om det finns mindre Àn 64 % MinFree RAM kvar pÄ vÀrden, kommer VM:ar som körs pÄ den att ha prestandaproblem.
I varje tillstÄnd tillÀmpas vissa minnesÄtervinningstekniker, som börjar med TPS, som praktiskt taget inte pÄverkar VM:arnas prestanda, och slutar med swapping. Jag ska berÀtta mer om dem.
Transparent Page Sharing (TPS). TPS Àr, grovt sagt, deduplicering av minnessidor för virtuella maskiner pÄ servern.
ESXi söker efter likadana minnessidor för virtuella maskiner, rÀknar och jÀmför hashvÀrden för sidorna, och tar bort dubbletter genom att ersÀtta dem med hÀnvisningar till samma sida i serverns fysiska minne. Som ett resultat minskar konsumtionen av fysiskt minne, och man kan uppnÄ viss överteckning av minnet praktiskt taget utan prestandaförlust.
Denna mekanism fungerar endast för minnessidor som Àr 4 KB stora (small pages). Hiper-V försöker inte ens deduplicera sidor som Àr 2 MB stora (large pages): Chansen att hitta likadana sidor av den storleken Àr inte stor.
Som standard tilldelar ESXi minne till stora sidor. Uppdelning av stora sidor till smÄ sidor börjar nÀr tröskeln för tillstÄndet High nÄs och sker tvingande nÀr tillstÄndet Clear nÄs (se hypervisorns tillstÄndstabell).
Om du vill att TPS ska börja arbeta utan att vĂ€nta pĂ„ att vĂ€rdens RAM ska fyllas, mĂ„ste du stĂ€lla in vĂ€rdet i Advanced Options pĂ„ ESXi âMem.AllocGuestLargePageâ till 0 (standardvĂ€rdet Ă€r 1). DĂ„ kommer allokeringen av stora sidor för virtuella maskiner att stĂ€ngas av.
FrÄn och med december 2014 Àr TPS som standard avstÀngt mellan VM i alla versioner av ESXi, eftersom en sÄrbarhet har upptÀckts som teoretiskt kan tillÄta Ätkomst till en annan VMs minne frÄn en VM. Mer information finns hÀr. Jag har inte sett nÄgon information om praktisk implementering av sÄrbarheten TPS.
TPS-policy kontrolleras genom avancerad option âMem.ShareForceSaltingâ pĂ„ ESXi:
0 â Inter-VM TPS. TPS fungerar för sidor frĂ„n olika VM;
1 â TPS för VM med samma vĂ€rde för âsched.mem.pshare.saltâ i VMX;
2 (standard) â Intra-VM TPS. TPS fungerar för sidor inom en VM.
Det Àr definitivt meningsfullt att stÀnga av stora sidor och aktivera Inter-VM TPS pÄ testbÀnkar. Detta kan ocksÄ anvÀndas för bÀnkar med ett stort antal liknande VM. Till exempel kan besparingen av fysisk minne pÄ VDI-bÀnkar nÄ tiotals procent.
Minne Ballooning. Ballooning Àr inte lÀngre en sÄ harmlös och genomskinlig teknik för VM:s operativsystem som TPS. Men med korrekt anvÀndning kan man leva med och till och med arbeta med Ballooning.
Tillsammans med VMware Tools installeras en speciell drivrutin pÄ VM som kallas Balloon Driver (Àven kÀnd som vmmemctl). NÀr hypervisorn börjar fÄ brist pÄ fysisk minne och gÄr in i ett Soft-lÀge, ber ESXi VM:n att ÄterlÀmna oanvÀnt RAM-minne via denna Balloon Driver. Drivrutinen arbetar i sin tur pÄ operativsystemsnivÄ och begÀr ledigt minne frÄn operativsystemet. Hypervisorn ser vilka sidor av det fysiska minnet som upptas av Balloon Driver, tar minne frÄn den virtuella maskinen och ÄterlÀmnar det till vÀrden. Det uppstÄr inga problem med operativsystemets arbete eftersom minnet pÄ operativsystemsnivÄ anvÀnds av Balloon Driver. Som standard kan Balloon Driver ta upp till 65% av VM:ns minne.
Om VMware Tools inte Àr installerade pÄ VM eller om Ballooning Àr avstÀngt (jag rekommenderar det inte, men det finns :), gÄr hypervisorn direkt över till mer drastiska tekniker för minnesavstÄende. Slutsats: Se till att VMware Tools Àr installerade pÄ VM.
Balloon Drivers arbete kan kontrolleras frÄn operativsystemet via VMware Tools..
Minnekomprimering. Denna teknik anvÀnds nÀr ESXi nÄr ett Hard-lÀge. Som namnet antyder försöker ESXi komprimera 4 KB-minnessidor till 2 KB och pÄ sÄ sÀtt frigöra lite utrymme i serverns fysiska minne. Denna teknik ökar avsevÀrt Ätkomsttiden till innehÄllet i VM:s minnessidor, eftersom sidan mÄste dekomprimeras först. Ibland gÄr det inte att komprimera alla sidor och sjÀlva processen tar lite tid. DÀrför Àr denna teknik i praktiken inte sÄ effektiv.
MinnesvÀxling. Efter en kort fas av minneskomprimering gÄr ESXi i stort sett ofrÄnkomligen (om inte VM:erna har flyttats till andra vÀrdar eller stÀngts av) över till vÀxling. Och om det finns mycket lite minne kvar (Low-lÀge), slutar hypervisorn ocksÄ att tilldela VM sidor av minnet, vilket kan orsaka problem i gÀstande operativsystem för VM.
SÄ hÀr fungerar Swapping. NÀr en virtuell maskin startas skapas en fil med filÀndelsen .vswp. Den Àr i storlek motsvarande det icke-reserverade RAM-minnet för VM: det Àr skillnaden mellan konfigurerat och reserverat minne. NÀr Swapping Àr aktiv, avlastar ESXi minnessidor frÄn den virtuella maskinen till denna fil och börjar anvÀnda den istÀllet för den fysiska serverminnet. SjÀlvklart Àr sÄdant "RAM" flera ordningar lÄngsammare Àn det verkliga, Àven om .vswp ligger pÄ snabb lagring.
Till skillnad frĂ„n Ballooning, dĂ€r VM tar bort oanvĂ€nda sidor, kan sidor som aktivt anvĂ€nds av OS eller applikationer inom VM flyttas till disken vid Swapping. Detta resulterar i att VM-prestandan sjunker ner till att nĂ€stan frysa. VM fungerar formellt och kan Ă„tminstone stĂ€ngas av korrekt frĂ„n OS. Om du Ă€r tĂ„lmodig đ
Om VM gÄr in i Swap Àr det en avvikelse som bör undvikas sÄ mycket som möjligt.
Huvudsakliga prestandaindikatorer för minnet av den virtuella maskinen
Nu har vi kommit till det viktigaste. För att övervaka minnesstatusen i VM finns följande indikatorer:
Aktiv â visar mĂ€ngden RAM-minne (KB) som VM har haft tillgĂ„ng till under den senaste mĂ€tperioden.
AnvĂ€ndning â samma som Aktiv, men i procent av den konfigurerade RAM-minnet för VM. BerĂ€knas enligt följande formel: aktiv Ă· storlek pĂ„ konfigurerat minne för den virtuella maskinen.
Hög AnvÀndning och Aktiv Àr inte alltid indikatorer pÄ prestandaproblem i VM. Om VM aggressivt anvÀnder minne (Ätminstone har tillgÄng till det) betyder det inte att minnet Àr otillrÀckligt. Snarare Àr det ett skÀl att kolla vad som hÀnder i OS.
Det finns en standardalarm för Memory Usage för VM:
Dela â mĂ€ngden RAM-minne för VM som har deduplicerats med hjĂ€lp av TPS (inom VM eller mellan VM).
Tilldelad â mĂ€ngden fysisk minne pĂ„ vĂ€rden (KB) som har tilldelats till VM. Inkluderar Dela.
Förbrukad (Tilldelad â Dela) â mĂ€ngden fysisk minne (KB) som VM konsumerar frĂ„n vĂ€rden. Inkluderar inte Dela.
Om en del av minnet för VM tilldelas inte frÄn vÀrdens fysiska minne, utan frÄn swap-filen eller minne tas bort frÄn VM via Balloon Driver, rÀknas detta inte in i Tilldelad och Förbrukad.
Höga vÀrden av Granted och Consumed Àr helt normala. Operativsystemet tar stegvis minne frÄn hypervisorn och ger inte tillbaka. Med tiden kommer vÀrdena för dessa rÀknare, för en aktivt fungerande VM, nÀrma sig den konfigurerade minnesstorleken och stanna dÀr.
Noll â mĂ€ngden arbetsminne för VM (KB) som innehĂ„ller nollor. SĂ„dant minne anses vara fritt av hypervisorn och kan ges till andra virtuella maskiner. Efter att det gĂ€stande operativsystemet har skrivit nĂ„got i minnet som har nollstĂ€llts gĂ„r det över till Consumed och Ă„tervĂ€nder aldrig.
Reserved Overhead â mĂ€ngden arbetsminne för VM (KB) som Ă€r reserverat av hypervisorn för att driva VM. Det Ă€r en liten mĂ€ngd, men den mĂ„ste alltid finnas tillgĂ€nglig pĂ„ vĂ€rden, annars startar inte VM.
Balloon â mĂ€ngden arbetsminne (KB) som tagits frĂ„n VM med hjĂ€lp av Balloon Driver.
Compressed â mĂ€ngden arbetsminne (KB) som har lyckats komprimeras.
Swapped â mĂ€ngden arbetsminne (KB) som, pĂ„ grund av brist pĂ„ fysisk minne pĂ„ servern, har flyttats till disken.
Balloon och de andra rÀknarna för minnesÄtervinning Àr noll.
SÄ hÀr ser grafen ut med rÀknarna för ett normalt fungerande VM med 150 GB arbetsminne.
I grafen nedan har VM uppenbara problem. Under grafen kan man se att alla beskrivna tekniker för arbetsminneshantering har anvÀnts för denna VM. Balloon för denna VM Àr mycket större Àn Consumed. Faktum Àr att VM Àr mer död Àn levande.
ESXTOP
Precis som med CPU, om vi snabbt vill bedöma situationen pÄ vÀrden och dess dynamik med intervall pÄ upp till 2 sekunder, bör vi anvÀnda ESXTOP.
ESXTOP-skÀrmen för minne kallas med tangenten "m" och ser ut som följer (fÀlten B,D,H,J,K,L,O Àr valda):
Intressanta parametrar för oss Àr följande:
Mem overcommit avg â genomsnittligt vĂ€rde för minnesoverskrivning pĂ„ vĂ€rden under 1, 5 och 15 minuter. Om det Ă€r över noll Ă€r det en anledning att titta pĂ„ vad som hĂ€nder, men det Ă€r inte alltid en indikator pĂ„ problem.
I raderna PMEM/MB och VMKMEM/MB â information om serverns fysiska minne och minnet som Ă€r tillgĂ€ngligt för VMkernel. HĂ€r kan intressant nog vĂ€rdet för minfree (i MB) och vĂ€rdens minnesstatus (i vĂ„rt fall, hög) ses.
I raden NUMA/MB kan man se fördelningen av arbetsminne över NUMA-noder (socklar). I detta exempel Àr fördelningen ojÀmt, vilket i princip inte Àr sÄ bra.
HÀr följer allmÀn statistik för servern angÄende minnesÄtervinningstekniker:
PSHARE/MB â detta Ă€r TPS-statistik;
SWAP/MB â statistik över anvĂ€ndning av Swap;
ZIP/MB â statistik för komprimering av minnessidor;
MEMCTL/MB â statistik för anvĂ€ndning av Balloon Driver.
För individuella VM kan följande information vara intressant. Jag har dolt namnen pÄ VM för att inte förvirra publiken :). Om metrik ESXTOP motsvarar rÀknaren i vSphere, ger jag motsvarande rÀknare.
MEMSZ â mĂ€ngden minne som konfigurerats för VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
GRANT â Granted i megabyte.
TCHD â Aktiv i megabyte.
MCTL? â om Balloon Driver Ă€r installerad pĂ„ VM.
MCTLSZ â Balloon i megabyte.
MCTLGT â mĂ€ngden RAM (megabyte) som ESXi vill Ă„terkrĂ€va frĂ„n VM via Balloon Driver (Memctl Target).
MCTLMAX â den maximala mĂ€ngden RAM (megabyte) som ESXi kan Ă„terkrĂ€va frĂ„n VM via Balloon Driver.
SWCUR â den nuvarande mĂ€ngden RAM (megabyte) som tilldelats VM frĂ„n Swap-filen.
SWGT â mĂ€ngden RAM (megabyte) som ESXi vill ge till VM frĂ„n Swap-filen (Swap Target).
Med hjÀlp av ESXTOP kan man ocksÄ se mer detaljerad information om VM:s NUMA-topologi. För detta mÄste fÀlten D,G vÀljas:
NHN â NUMA-noder dĂ€r VM Ă€r placerad. HĂ€r kan man omedelbart lĂ€gga mĂ€rke till breda VM som inte fĂ„r plats pĂ„ en enda NUMA-nod.
NRMEM â hur mĂ„nga megabyte minne VM tar frĂ„n en avlĂ€gsen NUMA-nod.
NLMEM â hur mĂ„nga megabyte minne VM tar frĂ„n en lokal NUMA-nod.
N%L â procent av minnet hos VM pĂ„ lokal NUMA-nod (om mindre Ă€n 80% â kan det uppstĂ„ prestandaproblem).
Minnet pÄ hypervisorn
Om CPU-rÀknarna för hypervisorn vanligtvis inte Àr av sÀrskilt intresse, sÄ Àr situationen olika med minnet. Hög minnesanvÀndning pÄ VM betyder inte alltid att det finns ett prestandaproblem, men hög minnesanvÀndning pÄ hypervisorn sÀtter igÄng minneshanteringstekniker och orsakar prestandaproblem för VM. Man bör övervaka larm för vÀrdminnesanvÀndning och undvika att VM hamnar i Swap.
Unswap
Om VM hamnar i Swap, minskar dess prestanda avsevÀrt. SpÄr av Ballooning och komprimering försvinner snabbt efter att det finns ledigt RAM pÄ vÀrden, men att ÄtervÀnda frÄn Swap till vÀrdens RAM gÄr inte snabbt för den virtuella maskinen.
Fram till ESXi 6.0 var den enda pÄlitliga och snabba metoden för att fÄ ut en virtuell maskin (VM) frÄn Swap att starta om (mer exakt att stÀnga av och sÀtta pÄ containern). FrÄn och med ESXi 6.0 finns det en, om Àn inte helt officiell, men fungerande och pÄlitlig metod för att fÄ ut VM frÄn Swap. PÄ en av konferenserna hade jag möjlighet att prata med en av ingenjörerna pÄ VMware som ansvarar för CPU-schemalÀggaren. Han bekrÀftade att metoden fungerar bra och Àr sÀker. I vÄr erfarenhet har vi inte haft nÄgra problem med det.
Kommandon för att fÄ ut en VM frÄn Swap Duncan Epping. Jag kommer inte att upprepa den detaljerade beskrivningen, utan jag ger bara ett exempel pÄ hur den anvÀnds. Som syns pÄ skÀrmdumpen försvinner Swap frÄn VM efter en viss tid nÀr kommandot har körts.
Tips för att hantera RAM-minne pÄ ESXi
Till sist, nÄgra tips som kan hjÀlpa dig att undvika prestandaproblem för VM pÄ grund av RAM-minne:
- Undvik överteckning av RAM-minne i produktiva kluster. Det Àr bra att alltid ha cirka 20-30% ledigt minne i klustret, sÄ att DRS (och administratören) har utrymme för manövrering, och vid migrering av VM inte gÄr till Swap. TÀnk ocksÄ pÄ reservkapacitet för redundans. Det Àr otrevligt nÀr en server gÄr ner och VM mÄste startas om med hjÀlp av HA, och en del maskiner gÄr dessutom till Swap.
- I infrastrukturer med hög konsolidering bör du undvika att skapa VM med mer Àn hÀlften av vÀrdminnet. Detta hjÀlper Äterigen DRS att fördela virtuella maskiner över servrar i klustret utan problem. SjÀlvklart Àr denna regel inte universell :).
- HÄll ett öga pÄ Host Memory Usage Alarm.
- Glöm inte att installera VMware Tools pÄ VM och stÀng av Ballooning.
- ĂvervĂ€g att aktivera Inter-VM TPS och stĂ€nga av Large Pages i VDI-miljöer och testmiljöer.
- Om VM har prestandaproblem, kontrollera om den anvÀnder minne frÄn en avlÀgsen NUMA-nod.
- FÄ ut VM frÄn Swap sÄ snabbt som möjligt! Förutom allt annat, om VM Àr i Swap, lider SAN av uppenbara skÀl.
Det Àr allt om RAM-minne för mig. Nedan finns artiklar i Àmnet för dem som vill fördjupa sig i detaljer. NÀsta artikel kommer att handla om lagring.
Nyttiga lÀnkar
KĂ€lla: habr.com
