Artikulu honetan vSphere-n ausazko sarbide memoria (RAM) errendimendu kontagailuei buruz hitz egingo dugu.
Badirudi memoriarekin dena argiago dagoela prozesadorearekin baino: VM batean errendimendu arazoak sortzen badira, zaila da haietaz ez ohartzea. Baina agertzen badira, askoz zailagoa da haiei aurre egitea. Baina lehen gauzak lehenik.
Teoria apur bat
Makina birtualen RAMa VMak exekutatzen ari diren zerbitzariaren memoriatik hartzen da. Hau nahiko argia da :). Zerbitzariaren RAMa denentzat nahikoa ez bada, ESXi memoria berreskuratzeko teknikak erabiltzen hasten da. Bestela, VM sistema eragileak huts egingo luke RAM sarbide akatsekin.
ESXi-k erabakitzen du zein teknika erabili RAM kargaren arabera:
Memoriaren egoera
mugatik
Jarduera
High
minen %400Doan
Goiko mugara iritsi ondoren, memoria-orri handiak txikitan banatzen dira (TPS modu estandarrean funtzionatzen du).
Eguraldi
minen %100Doan
Memoria handiko orriak txikitan banatzen dira, TPS behartuta dago.
Soft
minen %64Doan
TPS + Puxika
Zaila
minen %32Doan
TPS + Konprimitu + Trukatu
Behe-
minen %16Doan
Konprimitu + Trukatu + Blokeatu
minFree hipervisora exekutatzeko beharrezkoa den RAM da.
ESXi 4.1 arte barne, minFree lehenespenez konpondu zen - zerbitzariaren RAMaren % 6 (ehunekoa ESXi-n Mem.MinFreePct aukeraren bidez alda zitekeen). Geroagoko bertsioetan, zerbitzarietan memoria hazi zela eta, minFree ostalariaren memoria kopuruaren arabera kalkulatzen hasi zen, eta ez portzentaje finkoaren balio gisa.
MinFree balioa (lehenetsia) honela kalkulatzen da:
MinFree-rako gordetako memoriaren ehunekoa
Memoria tartea
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Geratzen den memoria
Adibidez, 128 GB RAM dituen zerbitzari baterako, MinFree balioa honako hau izango da:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
Benetako balioa ehunka MB desberdina izan daiteke, zerbitzariaren eta RAMaren arabera.
MinFree-rako gordetako memoriaren ehunekoa
Memoria tartea
128 GB-ren balioa
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Gainerako memoria (100 GB)
1024 MB
Normalean, stand produktiboetarako, Goi-egoera soilik normaltzat har daiteke. Proba eta garapen-bankuetarako, egoera argiak/leunak onar daitezke. Ostalariaren RAM% 64 MinFree baino txikiagoa bada, orduan exekutatzen diren VM-ek errendimendu arazoak izaten dituzte zalantzarik gabe.
Egoera bakoitzean, memoria berreskuratzeko teknika batzuk erabiltzen dira, TPS-tik hasita, zeinak ia ez du eraginik VM-ren errendimenduan, Trukeraino. Horiei buruz gehiago kontatuko dizuet.
Orrialdea partekatzea gardena (TPS). TPS, gutxi gorabehera, zerbitzariko makina birtualen RAM orrien desduplicazioa da.
ESXi-k makina birtualeko RAM orrialde berdinak bilatzen ditu orrien hash batura zenbatu eta alderatuz, eta bikoiztutako orrialdeak kentzen ditu, zerbitzariaren memoria fisikoko orrialde bereko erreferentziak jarriz. Ondorioz, memoria fisikoaren kontsumoa murrizten da eta memoriaren gehiegizko harpidetza lor daiteke ia errendimenduko eraginik gabe.
Mekanismo honek 4 KB-ko tamainako memoria-orrietarako bakarrik funtzionatzen du (orri txikiak). Hipervisoria ez da 2 MBko tamainako orrialdeak (orri handiak) desbikoiatzen ere saiatzen: tamaina horretako orrialde berdinak aurkitzeko aukera ez da handia.
Lehenespenez, ESXi-k memoria orri handietara esleitzen du. Orrialde handiak orrialde txikietan zatitzea Goi-egoera atalasea iristen denean hasten da eta Garbitu egoerara iristen denean behartzen da (ikus hipervisorearen egoera-taula).
TPS ostalariaren RAMa bete arte itxaron gabe lanean hastea nahi baduzu, ESXi Aukera Aurreratuetan ezarri behar duzu balioa. "Mem.AllocGuestLargePage" 0ra (lehenetsia 1). Ondoren, makina birtualetarako memoria-orri handien esleipena desgaitu egingo da.
2014ko abenduaz geroztik, ESXi bertsio guztietan, VM arteko TPS lehenespenez desgaituta dago, teorikoki VM bati beste VM baten RAMra sartzea ahalbidetzen duen ahultasun bat aurkitu baita. Xehetasunak hemen. Ez dut TPS ahultasuna ustiatzearen inplementazio praktikoari buruzko informaziorik topatu.
TPS politika aukera aurreratuen bidez kontrolatzen da "Mem.ShareForceSalting" ESXi-n:
0 - VM arteko TPS. TPS-k VM desberdinetako orrialdeetarako funtzionatzen du;
1 - VMX-n "sched.mem.pshare.salt" balio bera duten VMetarako TPS;
2 (lehenetsia) - VM barneko TPS. TPS-k VM baten barruan dauden orrialdeetarako funtzionatzen du.
Zalantzarik gabe, zentzuzkoa da orrialde handiak desgaitzea eta Inter-VM TPS proba-bankuetan gaitzea. Hau antzeko VM kopuru handia duten standetarako ere erabil daiteke. Adibidez, VDI duten standetan, memoria fisikoan aurreztea ehuneko hamarnara irits daiteke.
Memoria Globoa. Globoa ez da VM sistema eragilearentzat TPS bezain teknika kaltegabe eta gardena. Baina behar bezala erabiltzen bada, Ballooning-ekin bizi eta lan egin dezakezu.
Vmware Tools-ekin batera, Balloon Driver (vmmemctl) izeneko kontrolatzaile berezi bat instalatzen da VM-n. Hipervisoria memoria fisikorik gabe geratzen hasten denean eta Soft egoeran sartzen denean, ESXi-k VM-ri eskatzen dio Balloon Driver honen bidez erabili gabeko RAM berreskura dezala. Gidariak, berriz, sistema eragilearen mailan lan egiten du eta memoria librea eskatzen dio. Hipervisoreak Balloon Driver-ek memoria fisikoko zein orrialde okupatu dituen ikusten du, makina birtualetik memoria hartzen du eta ostalarira itzultzen du. OSaren funtzionamenduarekin ez dago arazorik, OS mailan memoria Balloon Driver-ek okupatzen baitu. Lehenespenez, Balloon Driver-ek VM memoriaren % 65 har dezake.
VMware Tools ez badago VM-n instalatuta edo Ballooning desgaituta badago (ez dut gomendatzen, baina badago :), hipervisorea berehala aldatzen da memoria kentzeko teknika zorrotzagoetara. Ondorioa: ziurtatu VMware Tools VM-n dagoela.
Balloon Driver-en funtzionamendua sistema eragiletik egiaztatu daiteke VMware Tools-en bidez.
Memoria Konpresioa. Teknika hau ESXi Hard egoerara iristen denean erabiltzen da. Izenak dioen bezala, ESXi-k 4KB RAM orrialde bat 2KB-tan konprimitzen saiatzen da, eta horrela zerbitzariaren memoria fisikoan leku pixka bat askatzen du. Teknika honek nabarmen handitzen du VM RAM orrien edukietara sartzeko denbora, lehenik orria deskonprimitu behar baita. Batzuetan orrialde guztiak ezin dira konprimitu eta prozesuak berak denbora pixka bat hartzen du. Beraz, teknika hau ez da oso eraginkorra praktikan.
Memoria trukatzea. Memoria-konpresioaren fase labur baten ondoren, ESXi ia ezinbestean (VM-ak beste ostalari batzuetara mugitu ez badira edo itzali ez badira) Swapping-era aldatzen da. Eta oso memoria gutxi geratzen bada (egoera baxua), orduan hipervisoreak memoria-orriak VM-ra esleitzeari ere uzten dio, eta horrek arazoak sor ditzake VM-ren OS gonbidatuan.
Honela funtzionatzen du Trukeak. Makina birtual bat pizten duzunean, .vswp luzapena duen fitxategi bat sortzen da horretarako. VM-ren erreserbarik gabeko RAMaren tamaina berdina da: hau da konfiguratutako eta erreserbatutako memoriaren arteko aldea. Trukatzea exekutatzen ari denean, ESXi-k makina birtualeko memoria-orriak fitxategi honetan trukatzen ditu eta horrekin lanean hasten da zerbitzariaren memoria fisikoaren ordez. Jakina, horrelako "RAM" memoria benetako memoria baino motelagoa da, .vswp biltegiratze azkarrean egon arren.
Ballooning ez bezala, erabiltzen ez diren orriak VM batetik hartzen direnean, OSak aktiboki erabiltzen dituen orriak edo VM barneko aplikazioak Swapping-ekin diskora eraman daitezke. Ondorioz, VMren errendimendua izozteraino jaisten da. VM formalki funtzionatzen ari da eta, gutxienez, behar bezala desgaitu daiteke sistema eragiletik. Pazientzia baduzu 😉
VM-ak Swap-era joan badira, ahalik eta hobekien saihestuko den larrialdi-egoera da.
Oinarrizko makina birtualeko memoriaren errendimendu-kontagailuak
Beraz, nagusira iritsi ginen. VM-ren memoria-egoera kontrolatzeko, kontagailu hauek daude:
Aktiboak — VM-ak aurreko neurketa-aldian atzitu zuen RAM kopurua (KB) erakusten du.
Erabilera — Aktiboaren berdina, baina VM konfiguratutako RAMaren ehuneko gisa. Formula hau erabiliz kalkulatua: aktiboa ÷ makina birtuala konfiguratutako memoria-tamaina.
Erabilera handia eta Aktiboa, hurrenez hurren, ez dira beti VM errendimendu-arazoen adierazle. VM-a oldarkorki erabiltzen ari bada memoria (gutxienez bertara sartzen), horrek ez du esan nahi nahikoa memoria ez dagoenik. Aitzitik, sistema eragilean gertatzen ari dena aztertzeko arrazoi bat da.
Memoriaren erabilerarako alarma estandar bat dago VMetarako:
Partekatua — TPS erabiliz desduplicatutako VM RAM kopurua (VM baten barruan edo VM artean).
Ematen — VMra esleitu zitzaion ostalari memoria fisikoaren (KB) kopurua. Partekatua gaitzen du.
kontsumitu (Emanda - Partekatua) - VM-k ostalaritik kontsumitzen duen memoria fisikoaren kopurua (KB). Ez du partekatua sartzen.
VM memoriaren zati bat ostalariaren memoria fisikotik ez bada ematen bada, trukatzeko fitxategi batetik baizik, edo memoria VMtik Balloon Driver-aren bidez hartzen bada, kopuru hori ez da kontuan hartuko Emandako eta Kontsumitutako atalean.
Emandako eta Kontsumitutako balio altuak guztiz normalak dira. Sistema eragileak apurka-apurka memoria hartzen du hipervisoretik eta ez dio itzultzen. Denborarekin, aktiboki exekutatzen ari den VM batean, kontagailu horien balioak konfiguratutako memoria kopurura hurbiltzen dira eta hor jarraitzen dute.
Zero — VM RAM kopurua (KB), zeroak dituena. Memoria hori libretzat jotzen du hipervisoreak eta beste makina birtualei eman diezaieke. Gonbidatutako sistema eragileak zeroed memorian zerbait idatzi ondoren, Kontsumituta sartzen da eta ez da itzultzen.
Erreserbatutako gastuak — Hipervisoreak VM funtzionatzeko erreserbatutako VM RAM kopurua (KB). Kopuru txikia da, baina ostalarian erabilgarri egon behar du, bestela VM ez da abiaraziko.
Balloon — Balloon Driver erabiliz VM-tik kendutako RAM kopurua (KB).
konprimitutako — konprimitu den RAM kopurua (KB).
Trukatu — RAM kopurua (KB), zeina, zerbitzarian memoria fisikorik ez zegoenez, diskora eramandakoa.
Globoen eta beste memoria berreskuratzeko tekniken kontagailuak zero dira.
Hau da grafikoaren itxura 150 GB RAM dituen VM normalean funtzionatzen duen VM baten Memoria-kontagailuekin.
Beheko grafikoan, VM-k arazo nabariak ditu. Grafikoaren azpian VM honetarako RAMarekin lan egiteko deskribatutako teknika guztiak erabili zirela ikus dezakezu. VM honetarako globoa Kontsumitua baino askoz handiagoa da. Izan ere, VM hilik dago bizirik baino.
ESXTOP
CPUarekin gertatzen den bezala, ostalariaren egoera, baita bere dinamika ere, 2 segundo arteko tartearekin azkar ebaluatu nahi badugu, ESXTOP erabili beharko genuke.
ESXTOP Memoria pantailara "m" teklarekin deitzen da eta itxura hau du (B,D,H,J,K,L,O eremuak hautatuta):
Parametro hauek interesgarriak izango zaizkigu:
Mem overcommit batez beste — Ostalariaren memoria gainharpidetzaren batez besteko balioa 1, 5 eta 15 minutuz. Zerotik gora badago, hori gertatzen ari dena aztertzeko arrazoi bat da, baina ez beti arazoen adierazle.
Lerroetan PMEM/MB и VMKMEM/MB — zerbitzariaren memoria fisikoari eta VMkernel-ek eskura duen memoriari buruzko informazioa. Hemen gauza interesgarrien artean minfree balioa (MB-tan) ikus dezakezu, ostalari-egoera memorian (gure kasuan, altua).
Ilaran NUMA/MB RAMaren banaketa ikus dezakezu NUMA nodoetan (socket). Adibide honetan, banaketa irregularra da, printzipioz ez da oso ona.
Honako hauek dira memoria berreskuratzeko tekniken zerbitzariaren estatistika orokorrak:
PSHARE/MB — TPS estatistikak dira;
TRUKATU/MB — Trukatu erabilera-estatistikak;
ZIP/MB — memoria-orrien konpresioaren estatistikak;
MEMCTL/MB — Balloon Driver-en erabilera-estatistikak.
Banakako VMetarako, ondorengo informazioa interesatuko zaigu. VM-en izenak ezkutatu ditut, publikoa ez nahasteko :). ESXTOP metrika vSphere-ko kontagailuaren antzekoa bada, dagokion kontagailua emango dut.
MEMSZ — VMn konfiguratutako memoria kopurua (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + ukitu gabe.
GRANT — MBtan emana.
TCHD — Aktiboa MBytetan.
MCTL? — Balloon Driver VM-n instalatuta dagoen ala ez.
MCTLSZ — Globoa MBra.
MCTLGT — ESXi-k VM-tik kendu nahi duen RAM kopurua (MByte) Globo kontrolatzailearen bidez (Memctl Target).
MCTLMAX — ESXi-k VM batetik kendu dezakeen RAM kopuru maximoa (MByte) Balloon Driver-en bidez.
SWCUR — Swap fitxategitik VM-ra esleitutako RAM kopurua (MBytes).
S.W.G.T. — ESXi-k VM-ri eman nahi dion RAM kopurua (MByte) Swap fitxategitik (Swap Target).
VMren NUMA topologiari buruzko informazio zehatzagoa ere ikus dezakezu ESXTOP bidez. Horretarako, hautatu D, G eremuak:
TXIKIA – VM kokatuta dagoen NUMA nodoak. Hemen berehala nabarituko duzu vm zabala, NUMA nodo batean sartzen ez direnak.
NRMEM – zenbat megabyte memoria hartzen dituen VM urruneko NUMA nodotik.
NLMEM – zenbat megabyteko memoria hartzen dituen VMak NUMA nodo lokaletik.
N%L – VM memoriaren ehunekoa NUMA nodo lokalean (% 80 baino txikiagoa bada, errendimendu arazoak sor daitezke).
Memoria hipervisorean
Hipervisoreko PUZaren kontagailuak normalean interes berezirik ez badute, memoriarekin egoera kontrakoa da. VM batean Memoria-erabilera handiak ez du beti errendimendu-arazorik adierazten, baina hipervisoreko Memoria-erabilerak altuak memoria kudeatzeko teknikak abiarazten ditu eta VM errendimenduarekin arazoak sortzen ditu. Ostalariaren memoria-erabileraren alarmak kontrolatu eta VM-ak Swap-en sartzea eragotzi behar duzu.
Destrukatu
VM bat Swap-en harrapatzen bada, bere errendimendua asko murrizten da. Globoaren eta konpresioaren aztarnak azkar desagertzen dira RAM librea ostalarian agertzen denean, baina makina birtualak ez du presarik Swap-etik zerbitzariaren RAMera itzultzeko.
ESXi 6.0 baino lehen, VM bat Swap-etik kentzeko modu fidagarri eta azkar bakarra berrabiaraztea zen (zehazkiago, edukiontzia itzaltzea/piztea). ESXi 6.0-tik hasita, guztiz ofiziala ez bada ere, VM bat Swap-etik kentzeko modu funtzionala eta fidagarria agertu da. Jardunaldietako batean, CPU Scheduler-en arduraduna den VMware ingeniarietako batekin hitz egin ahal izan nuen. Metodoa nahiko funtzionala eta segurua dela baieztatu zuen. Gure esperientziaren arabera, horrekin ere ez zegoen arazorik.
VM bat Swap-etik kentzeko benetako komandoak Duncan Epping. Ez dut deskribapen zehatza errepikatuko, erabileraren adibide bat besterik ez dut emango. Pantaila-argazkian ikus dezakezun bezala, zehaztutako komandoa exekutatu ondoren, Swap on the VM desagertzen da.
RAM ESXi-n kudeatzeko aholkuak
Azkenik, hona hemen RAMaren ondorioz VM errendimenduarekin arazoak saihesten lagunduko dizuten aholku batzuk:
- Saihestu RAMaren gehiegizko harpidetza kluster produktiboetan. Komeni da memoria librearen %20-30 beti edukitzea klusterrean, DRSek (eta administratzaileak) maniobra egiteko tartea izan dezaten eta VM-ak ez daitezen Swap-era joan migrazioan. Gainera, ez ahaztu akatsen tolerantziarako marjina. Desatsegina da zerbitzari batek huts egiten duenean eta VM-a HA erabiliz berrabiarazten denean, makina batzuk Swap-era doazenean ere.
- Oso sendotutako azpiegituretan, saiatu EZ sortzen ostalariaren memoriaren erdia baino memoria handiagoa duten VM-ak. Horrek berriro lagunduko dio DRS-ri makina birtualak kluster zerbitzarietan arazorik gabe banatzen. Arau hau, noski, ez da unibertsala :).
- Kontuz ostalariaren memoria erabiltzearen alarmarekin.
- Ez ahaztu VMware Tools VM-n instalatzea eta ez desaktibatu Globoak.
- Demagun VM arteko TPS gaitzea eta orrialde handiak desgaitzea VDI eta proba-inguruneetan.
- VM-ak errendimendu-arazoak baditu, egiaztatu urruneko NUMA nodo bateko memoria erabiltzen ari ote den.
- Kendu VM-ak Swap-etik ahalik eta azkarren! Besteak beste, VM-a Swap-en badago, biltegiratze-sistemak ageriko arrazoiengatik jasaten du.
Hori da niretzat RAMari buruzko guztia. Jarraian, sakondu nahi dutenentzako erlazionatutako artikuluak daude. Hurrengo artikulua biltegiari eskainiko zaio.
Esteka interesgarriak
Iturria: www.habr.com