I den här artikeln kommer vi att prata om prestandaräknare för RAM (Random Access Memory) i vSphere.
Det verkar som om allt med minne är tydligare än med processorn: om prestandaproblem uppstår på en virtuell dator är det svårt att inte märka dem. Men om de dyker upp är det mycket svårare att hantera dem. Men först till kvarn.
Lite teori
RAM-minnet för virtuella maskiner tas från minnet på servern som de virtuella datorerna körs på. Detta är ganska uppenbart :). Om serverns RAM inte räcker till för alla börjar ESXi använda tekniker för minnesåtervinning. Annars skulle VM-operativsystemen krascha med RAM-åtkomstfel.
ESXi bestämmer vilka tekniker som ska användas beroende på RAM-belastningen:
Minnesstatus
gräns
Aktivitet
Hög
400 % av minGratis
Efter att ha nått den övre gränsen delas stora minnessidor upp i små (TPS fungerar i standardläge).
Rensa
100 % av minGratis
Stora minnessidor delas upp i små, TPS tvingas.
Mjuk
64 % av minGratis
TPS + ballong
Hård
32 % av minGratis
TPS + Komprimera + Byt
Låg
16 % av minGratis
Komprimera + Byt + Blockera
minFree är RAM-minnet som krävs för att hypervisorn ska köras.
Upp till ESXi 4.1 inklusive, var minFree fixad som standard - 6% av serverns RAM-minne (procentandelen kunde ändras via Mem.MinFreePct-alternativet på ESXi). I senare versioner, på grund av tillväxten av minne på servrar, började minFree beräknas baserat på mängden minne hos värden, och inte som ett fast procentuellt värde.
MinFree-värdet (standard) beräknas enligt följande:
Procent av minne reserverat för minFree
Minnesräckvidd
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, kommer MinFree-värdet att vara följande:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Det faktiska värdet kan skilja sig med ett par hundra MB, beroende på server och RAM.
Procent av minne reserverat för minFree
Minnesräckvidd
Värde 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, för produktiva bestånd, kan endast det höga tillståndet anses vara normalt. För test- och utvecklingsbänkar kan Clear/Soft-tillstånd vara acceptabla. Om RAM-minnet på värden är mindre än 64 % MinFree, har de virtuella datorerna som körs på den definitivt prestandaproblem.
I varje tillstånd används vissa tekniker för minnesåtervinning, från TPS, som praktiskt taget inte har någon effekt på VM-prestanda, till Swapping. Jag ska berätta mer om dem.
Transparent siddelning (TPS). TPS är, grovt sett, deduplicering av RAM-sidor på virtuella maskiner på servern.
ESXi söker efter identiska virtuella maskin-RAM-sidor genom att räkna och jämföra hashsumman för sidorna, och tar bort dubbletter av sidor och ersätter dem med referenser till samma sida i serverns fysiska minne. Som ett resultat minskar den fysiska minnesförbrukningen och viss minnesöverteckning kan uppnås med praktiskt taget ingen prestandapåverkan.
Denna mekanism fungerar endast för minnessidor på 4 KB i storlek (små sidor). Hypervisorn försöker inte ens deduplicera sidor som är 2 MB stora (stora sidor): chansen att hitta identiska sidor av denna storlek är inte stor.
Som standard allokerar ESXi minne till stora sidor. Att dela upp stora sidor i små sidor börjar när tröskeln för det höga tillståndet nås och tvingas fram när tillståndet Rensa nås (se tabellen för hypervisortillstånd).
Om du vill att TPS ska börja arbeta utan att vänta på att värdminnet ska vara fullt, måste du ställa in värdet i Advanced Options ESXi "Mem.AllocGuestLargePage" till 0 (standard 1). Då kommer tilldelningen av stora minnessidor för virtuella maskiner att inaktiveras.
Sedan december 2014, i alla ESXi-versioner, är TPS mellan virtuella datorer inaktiverat som standard, eftersom en sårbarhet upptäcktes som teoretiskt tillåter en virtuell dator att komma åt RAM-minnet på en annan virtuell dator. Detaljer här. Jag har inte stött på information om den praktiska implementeringen av att utnyttja TPS-sårbarheten.
TPS-policy styrs via avancerat alternativ "Mem.ShareForceSalting" på ESXi:
0 - Inter-VM TPS. TPS fungerar för sidor i olika virtuella datorer;
1 – TPS för virtuella datorer med samma "sched.mem.pshare.salt"-värde i VMX;
2 (standard) – Intra-VM TPS. TPS fungerar för sidor i en virtuell dator.
Det är definitivt vettigt att inaktivera stora sidor och aktivera Inter-VM TPS på testbänkar. Detta kan även användas för montrar med ett stort antal liknande virtuella datorer. Till exempel på montrar med VDI kan besparingar i fysiskt minne uppgå till tiotals procent.
Minnesballongflygning. Ballongflygning är inte längre en så ofarlig och transparent teknik för VM-operativsystemet som TPS. Men om den används på rätt sätt kan du leva och till och med arbeta med ballongflygning.
Tillsammans med Vmware Tools är en speciell drivrutin som heter Balloon Driver (alias vmmemctl) installerad på den virtuella datorn. När hypervisorn börjar få slut på fysiskt minne och går in i mjukt tillstånd, ber ESXi den virtuella datorn att återta oanvänt RAM-minne genom denna ballongdrivrutin. Drivrutinen arbetar i sin tur på operativsystemnivå och begär ledigt minne från den. Hypervisorn ser vilka sidor i det fysiska minnet som ballongföraren har upptagit, tar minnet från den virtuella maskinen och returnerar det till värden. Det finns inga problem med driften av operativsystemet, eftersom minnet på OS-nivå är upptaget av ballongdrivrutinen. Som standard kan Balloon Driver ta upp till 65 % av VM-minnet.
Om VMware Tools inte är installerade på den virtuella datorn eller Ballooning är inaktiverat (jag rekommenderar det inte, men det finns :), hypervisorn byter omedelbart till strängare tekniker för att ta bort minne. Slutsats: se till att VMware Tools finns på den virtuella datorn.
Funktionen av Balloon Driver kan kontrolleras från operativsystemet via VMware Tools.
Minneskomprimering. Denna teknik används när ESXi når det hårda tillståndet. Som namnet antyder försöker ESXi komprimera en 4KB-sida med RAM till 2KB, och därigenom frigöra lite utrymme i serverns fysiska minne. Denna teknik ökar åtkomsttiden till innehållet på VM RAM-sidor avsevärt, eftersom sidan först måste dekomprimeras. Ibland kan inte alla sidor komprimeras och själva processen tar lite tid. Därför är denna teknik inte särskilt effektiv i praktiken.
Minnesbyte. Efter en kort fas av minneskomprimering växlar ESXi nästan oundvikligen (om de virtuella datorerna inte har flyttat till andra värdar eller inte är avstängda) till Swapping. Och om det finns väldigt lite minne kvar (lågt tillstånd) slutar hypervisorn också att allokera minnessidor till den virtuella datorn, vilket kan orsaka problem i den virtuella datorns gäst-OS.
Så här fungerar Swapping. När du slår på en virtuell maskin skapas en fil med filtillägget .vswp för den. Den är lika stor som den virtuella datorns oreserverade RAM: detta är skillnaden mellan konfigurerat och reserverat minne. När Swapping körs byter ESXi virtuella maskinminnessidor till den här filen och börjar arbeta med den istället för serverns fysiska minne. Naturligtvis är sådant "RAM"-minne flera storleksordningar långsammare än verkligt minne, även om .vswp är på snabb lagring.
Till skillnad från Ballooning, när oanvända sidor tas från en virtuell dator, kan byta sidor som aktivt används av operativsystemet eller applikationer inuti den virtuella datorn flyttas till disk. Som ett resultat sjunker prestandan för den virtuella datorn till att den fryser. Den virtuella datorn fungerar formellt och den kan åtminstone inaktiveras korrekt från operativsystemet. Om du har tålamod 😉
Om virtuella datorer har gått till Swap är detta en nödsituation som bäst undviks om möjligt.
Grundläggande prestandaräknare för virtuell maskinminne
Så vi kom till huvudsaken. För att övervaka minnestillståndet för den virtuella datorn finns följande räknare:
Aktiva — visar mängden RAM (KB) som den virtuella datorn fick åtkomst till under föregående mätperiod.
Användning — samma som Active, men som en procentandel av den virtuella datorns konfigurerade RAM. Beräknas med följande formel: aktiv ÷ virtuell maskin konfigurerad minnesstorlek.
High Usage respektive Active är inte alltid en indikator på VM-prestandaproblem. Om den virtuella datorn aggressivt använder minne (åtminstone kommer åt det), betyder det inte att det inte finns tillräckligt med minne. Detta är snarare en anledning att titta på vad som händer i operativsystemet.
Det finns ett standardlarm för minnesanvändning för virtuella datorer:
Delade — Mängden virtuellt RAM-minne som deduplicerats med hjälp av TPS (inom en virtuell dator eller mellan virtuella datorer).
Beviljas — mängden fysiskt värdminne (KB) som tilldelades den virtuella datorn. Aktiverar delad.
Förbrukad (Beviljat - Delat) - mängden fysiskt minne (KB) som den virtuella datorn förbrukar från värden. Inkluderar inte Shared.
Om en del av VM-minnet inte ges från värdens fysiska minne, utan från en växlingsfil, eller om minnet tas från VM:n via ballongdrivrutinen, tas inte detta belopp med i beräkningen i Granted and Consumed.
Höga beviljade och förbrukade värden är helt normala. Operativsystemet tar gradvis minne från hypervisorn och ger det inte tillbaka. Med tiden, i en aktivt körande virtuell dator, närmar sig värdena för dessa räknare mängden konfigurerat minne och förblir där.
Noll — mängden VM RAM (KB), som innehåller nollor. Sådant minne anses vara fritt av hypervisorn och kan ges till andra virtuella maskiner. Efter att gästoperativsystemet har skrivit något till nollställt minne, går det till Consumed och återgår inte.
Reserverad overhead — mängden VM RAM, (KB) som reserverats av hypervisorn för VM-drift. Detta är ett litet belopp, men det måste vara tillgängligt på värden, annars startar inte den virtuella datorn.
Ballong — mängden RAM (KB) som tagits bort från den virtuella datorn med hjälp av Balloon Driver.
Komprimerad — mängden RAM (KB) som komprimerades.
Swappat — mängden RAM (KB) som, på grund av bristen på fysiskt minne på servern, flyttade till disk.
Räknare för ballong- och andra minnesåtervinningstekniker är noll.
Så här ser grafen ut med minnesräknare för en normalt fungerande virtuell dator med 150 GB RAM.
I grafen nedan har VM:n uppenbara problem. Nedanför grafen kan du se att för denna virtuella dator användes alla beskrivna tekniker för att arbeta med RAM. Ballongen för denna virtuella dator är mycket större än Consumed. Faktum är att VM är mer död än levande.
ESXTOP
Som med CPU:n, om vi snabbt vill bedöma situationen på värden, såväl som dess dynamik med ett intervall på upp till 2 sekunder, bör vi använda ESXTOP.
ESXTOP Memory-skärmen tas fram med "m"-tangenten och ser ut så här (fälten B,D,H,J,K,L,O valda):
Följande parametrar kommer att vara av intresse för oss:
Mem overcommit avg — Genomsnittligt värde för minnesöverteckning på värden under 1, 5 och 15 minuter. Om det är över noll, så är detta en anledning att titta på vad som händer, men inte alltid en indikator på problem.
I rader PMEM/MB и VMKMEM/MB — information om det fysiska minnet på servern och det minne som är tillgängligt för VMkernel. Bland de intressanta sakerna här kan du se minfree-värdet (i MB), värdtillståndet i minnet (i vårt fall högt).
I kö NUMA/MB du kan se fördelningen av RAM över NUMA-noder (sockets). I det här exemplet är fördelningen ojämn, vilket i princip inte är särskilt bra.
Följande är allmän serverstatistik för tekniker för minnesåtervinning:
PSHARE/MB — Detta är TPS-statistik.
BYTTA/MB — Swap användningsstatistik;
ZIP/MB — statistik för komprimering av minnessidor;
MEMCTL/MB — Användningsstatistik för ballongförare.
För enskilda virtuella datorer kan vi vara intresserade av följande information. Jag gömde namnen på virtuella datorer för att inte förvirra publiken :). Om ESXTOP-måttet liknar räknaren i vSphere kommer jag att tillhandahålla motsvarande räknare.
MEMSZ — mängden minne som konfigurerats på den virtuella datorn (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + orörd.
BEVILJA — Beviljas i MB.
TCHD — Aktiv i MBytes.
MCTL? — om ballongdrivrutinen är installerad på den virtuella datorn.
MCTLSZ — Ballong till MB.
MCTLGT — mängden RAM (MByte) som ESXi vill ta bort från den virtuella datorn via ballongdrivrutinen (Memctl Target).
MCTLMAX — den maximala mängden RAM (MByte) som ESXi kan ta bort från en virtuell dator via ballongdrivrutinen.
SWCUR — den aktuella mängden RAM (MByte) som tilldelats den virtuella datorn från växlingsfilen.
S.W.G.T. — mängden RAM (MByte) som ESXi vill ge till den virtuella datorn från växlingsfilen (Swap Target).
Du kan också se mer detaljerad information om den virtuella datorns NUMA-topologi genom ESXTOP. För att göra detta, välj fält D, G:
SMÅ – NUMA noder där den virtuella datorn är placerad. Här kan du omedelbart märka bred vm, som inte passar på en NUMA-nod.
NRMEM – hur många megabyte minne den virtuella datorn tar från den fjärranslutna NUMA-noden.
NLMEM – hur många megabyte minne den virtuella datorn tar från den lokala NUMA-noden.
N%L – procentandel av VM-minnet på den lokala NUMA-noden (om mindre än 80 % kan prestandaproblem uppstå).
Minne på hypervisorn
Om CPU-räknare för en hypervisor vanligtvis inte är av särskilt intresse, är situationen den motsatta med minnet. Hög minnesanvändning på en virtuell dator indikerar inte alltid ett prestandaproblem, men hög minnesanvändning på en hypervisor utlöser tekniker för minneshantering och orsakar problem med den virtuella datorns prestanda. Du måste övervaka värdminnesanvändningslarm och förhindra virtuella datorer från att komma in i Swap.
Ta bort bytet
Om en virtuell dator fastnar i Swap, försämras dess prestanda avsevärt. Spår av ballongflygning och komprimering försvinner snabbt efter att ledigt RAM-minne dyker upp på värden, men den virtuella maskinen har ingen brådska att återvända från Swap till serverns RAM.
Före ESXi 6.0 var det enda pålitliga och snabba sättet att ta bort en virtuell dator från Swap att starta om (mer exakt, stänga av/sätta på behållaren). Från och med ESXi 6.0, även om det inte är helt officiellt, har ett fungerande och pålitligt sätt att ta bort en virtuell dator från Swap dykt upp. På en av konferenserna kunde jag prata med en av VMware-ingenjörerna som ansvarade för CPU Scheduler. Han bekräftade att metoden är ganska fungerande och säker. Enligt vår erfarenhet var det inga problem med det heller.
De faktiska kommandona för att ta bort en virtuell dator från Swap Duncan Epping. Jag kommer inte att upprepa den detaljerade beskrivningen, jag ska bara ge ett exempel på dess användning. Som du kan se på skärmdumpen försvinner Swap på den virtuella datorn en tid efter att du har utfört det angivna kommandot.
Tips för att hantera RAM på ESXi
Slutligen, här är några tips som hjälper dig att undvika problem med VM-prestanda på grund av RAM:
- Undvik överprenumeration av RAM-minne i produktiva kluster. Det är lämpligt att alltid ha ~20-30% ledigt minne i klustret så att DRS (och administratören) har utrymme att manövrera och virtuella datorer inte går till Swap under migreringen. Glöm inte heller marginalen för feltolerans. Det är obehagligt när, när en server misslyckas och den virtuella datorn startas om med HA, några av maskinerna också går till Swap.
- I starkt konsoliderade infrastrukturer, försök att INTE skapa virtuella datorer med minne som är större än hälften av värdminnet. Detta kommer återigen att hjälpa DRS att distribuera virtuella maskiner över klusterservrar utan problem. Denna regel är naturligtvis inte universell :).
- Se upp för värdminnesanvändningslarm.
- Glöm inte att installera VMware Tools på den virtuella datorn och stäng inte av Ballooning.
- Överväg att aktivera Inter-VM TPS och inaktivera stora sidor i VDI- och testmiljöer.
- Om den virtuella datorn har prestandaproblem, kontrollera om den använder minne från en fjärransluten NUMA-nod.
- Ta bort virtuella datorer från Swap så snabbt som möjligt! Om den virtuella datorn bland annat är i Swap så lider lagringssystemet av förklarliga skäl.
Det är allt för mig om RAM. Nedan finns relaterade artiklar för den som vill gå djupare. Nästa artikel kommer att ägnas åt storaj.
Användbara länkar
Källa: will.com