En ĉi tiu artikolo ni parolos pri hazarda alirmemoro (RAM) agado-nombriloj en vSphere.
Ŝajnas, ke kun memoro ĉio estas pli klara ol kun la procesoro: se aperaj problemoj aperas sur VM, estas malfacile ne rimarki ilin. Sed se ili aperas, estas multe pli malfacile trakti ilin. Sed unue aferojn.
Iom teorio
La RAM de virtualaj maŝinoj estas prenita de la memoro de la servilo sur kiu la VMs funkcias. Ĉi tio estas sufiĉe evidenta :). Se la RAM de la servilo ne sufiĉas por ĉiuj, ESXi komencas uzi memorajn reklamajn teknikojn. Alie, la VM-operaciumoj kraŝus kun RAM-aliraj eraroj.
ESXi decidas kiujn teknikojn uzi depende de la RAM-ŝarĝo:
Memorstatuso
Limo
Agoj
alta
400% de min Senpaga
Post atingi la supran limon, grandaj memorpaĝoj estas dividitaj en malgrandajn (TPS funkcias en norma reĝimo).
klara
100% de min Senpaga
Grandaj memorpaĝoj estas dividitaj en malgrandajn, TPS estas devigita.
mola
64% de min Senpaga
TPS + Balono
malfacila
32% de min Senpaga
TPS + Kunpremo + Interŝanĝo
malalte
16% de min Senpaga
Kunpremu + Ŝanĝi + Bloki
minFree estas la RAM necesa por ke la hiperviziero funkciigu.
Ĝis ESXi 4.1 inkluzive, minFree estis fiksita defaŭlte - 6% de la RAM de la servilo (la procento povus esti ŝanĝita per la opcio Mem.MinFreePct sur ESXi). En pli postaj versioj, pro la kresko de memoro sur serviloj, minFree komencis esti kalkulita surbaze de la kvanto de memoro de la gastiganto, kaj ne kiel fiksa procentvaloro.
La minFree-valoro (defaŭlte) estas kalkulita jene:
Procento de memoro rezervita por minFree
Memora gamo
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
Restanta Memoro
Ekzemple, por servilo kun 128 GB da RAM, la valoro de MinFree estos kiel sekvas:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 MB = 1,88 GB
La reala valoro povas malsami je kelkaj cent MB, depende de la servilo kaj RAM.
Procento de memoro rezervita por minFree
Memora gamo
Valoro por 128 GB
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Restanta memoro (100 GB)
1024 MB
Tipe, por produktivaj standoj, nur la Alta stato povas esti konsiderita normala. Por testaj kaj evoluaj benkoj, Klaraj/Molaj ŝtatoj povas esti akcepteblaj. Se la RAM sur la gastiganto estas malpli ol 64% MinFree, tiam la VM-oj kurantaj sur ĝi sendube spertas rendimentajn problemojn.
En ĉiu ŝtato, certaj memorreklamaj teknikoj estas uzitaj, komencante de TPS, kiu havas praktike neniun efikon al VM-efikeco, ĝis Interŝanĝado. Mi rakontos al vi pli pri ili.
Travidebla Paĝa Kundivido (TPS). TPS estas, proksimume, deduplikado de RAM-paĝoj de virtualaj maŝinoj sur la servilo.
ESXi serĉas identajn virtualajn maŝinajn RAM-paĝojn per nombrado kaj komparado de la hashsumo de la paĝoj, kaj forigas duplikatajn paĝojn, anstataŭigante ilin per referencoj al la sama paĝo en la fizika memoro de la servilo. Kiel rezulto, fizika memorkonsumo estas reduktita kaj iu memora troabono povas esti atingita kun praktike neniu efikeco efiko.
Ĉi tiu mekanismo funkcias nur por memorpaĝoj de 4 KB en grandeco (malgrandaj paĝoj). La hiperviziero eĉ ne provas dedupliki paĝojn kun grandeco de 2 MB (grandaj paĝoj): la ŝanco trovi identajn paĝojn de ĉi tiu grandeco ne estas granda.
Defaŭlte, ESXi asignas memoron al grandaj paĝoj. Dividi grandajn paĝojn en malgrandajn paĝojn komenciĝas kiam la Alta ŝtata sojlo estas atingita kaj estas devigita kiam la Klara stato estas atingita (vidu la hipervizian statotabelon).
Se vi volas, ke TPS ekfunkciu sen atendi ke la gastiga RAM estos plena, vi devas agordi la valoron en Altnivelaj Opcioj ESXi "Mem.AllocGuestLargePage" al 0 (defaŭlte 1). Tiam la atribuo de grandaj memorpaĝoj por virtualaj maŝinoj estos malŝaltita.
Ekde decembro 2014, en ĉiuj ESXi-eldonoj, TPS inter VM-oj estas malŝaltita defaŭlte, ĉar vundebleco estis trovita, kiu teorie permesas al unu VM aliri la RAM de alia VM. Detaloj ĉi tie. Mi ne trovis informojn pri la praktika efektivigo de ekspluatado de la vundebleco de TPS.
TPS-politiko estas kontrolita per altnivela opcio "Mem.ShareForceSalting" sur ESXi:
0 - Inter-VM TPS. TPS funkcias por paĝoj de malsamaj VM-oj;
1 - TPS por VM-oj kun la sama valoro "sched.mem.pshare.salt" en VMX;
2 (defaŭlte) - Intra-VM TPS. TPS funkcias por paĝoj ene de VM.
Nepre havas sencon malŝalti grandajn paĝojn kaj ebligi Inter-VM TPS sur testbenkoj. Ĉi tio ankaŭ povas esti uzata por standoj kun granda nombro da similaj VM-oj. Ekzemple, sur standoj kun VDI, ŝparoj en fizika memoro povas atingi dekojn de procentoj.
Memorbalonado. Balonado ne plu estas tia sendanĝera kaj travidebla tekniko por la VM-operaciumo kiel TPS. Sed se uzata ĝuste, vi povas vivi kaj eĉ labori kun Balonado.
Kune kun Vmware Tools, speciala ŝoforo nomita Balloon Driver (alinome vmmemctl) estas instalita sur la VM. Kiam la hiperviziero komencas elĉerpi fizikan memoron kaj eniras la Molan staton, ESXi petas al la VM reakiri neuzatan RAM per ĉi tiu Balloon Driver. La ŝoforo, siavice, funkcias je la mastruma sistemo kaj petas liberan memoron de ĝi. La hiperviziero vidas, kiujn paĝojn de fizika memoro okupis la Balona Ŝoforo, prenas memoron de la virtuala maŝino kaj resendas ĝin al la gastiganto. Ne estas problemoj kun la funkciado de la OS, ĉar ĉe la OS-nivelo la memoro estas okupata de la Balloon Driver. Defaŭlte, Balloon Driver povas preni ĝis 65% de VM-memoro.
Se VMware Tools ne estas instalita sur la VM aŭ Balooning estas malŝaltita (mi ne rekomendas ĝin, sed ekzistas :), la hiperviziero tuj ŝanĝas al pli striktaj teknikoj por forigi memoron. Konkludo: certigu, ke VMware Tools estas sur la VM.
La funkciado de Balloon Driver povas esti kontrolita de la OS per VMware Tools.
Memora Kunpremo. Ĉi tiu tekniko estas uzata kiam ESXi atingas la Malmolan staton. Kiel la nomo sugestas, ESXi provas kunpremi 4KB paĝon de RAM en 2KB, tiel liberigante iom da spaco en la fizika memoro de la servilo. Ĉi tiu tekniko signife pliigas la alirtempon al la enhavo de VM RAM-paĝoj, ĉar la paĝo unue devas esti malkunpremita. Foje ne ĉiuj paĝoj povas esti kunpremitaj kaj la procezo mem prenas iom da tempo. Tial ĉi tiu tekniko ne estas tre efika en la praktiko.
Memorinterŝanĝo. Post mallonga fazo de Memora Kunpremo, ESXi preskaŭ neeviteble (se la VMs ne moviĝis al aliaj gastigantoj aŭ ne estas malŝaltitaj) ŝanĝas al Interŝanĝo. Kaj se restas tre malmulte da memoro (Malalta stato), tiam la hiperviziero ankaŭ ĉesas atribui memorpaĝojn al la VM, kio povas kaŭzi problemojn en la gasto OS de la VM.
Tiel funkcias Interŝanĝado. Kiam vi ŝaltas virtualan maŝinon, dosiero kun etendo .vswp estas kreita por ĝi. Ĝi estas egala en grandeco al la nerezervita RAM de la VM: ĉi tio estas la diferenco inter agordita kaj rezervita memoro. Kiam Interŝanĝo funkcias, ESXi interŝanĝas virtualajn maŝinajn memorpaĝojn en ĉi tiun dosieron kaj komencas labori kun ĝi anstataŭ la fizika memoro de la servilo. Kompreneble, tia "RAM" memoro estas pluraj ordoj de grandeco pli malrapida ol reala memoro, eĉ se la .vswp estas sur rapida stokado.
Male al Balonado, kiam neuzataj paĝoj estas prenitaj de VM, kun Interŝanĝaj paĝoj kiuj estas aktive uzataj de la OS aŭ aplikoj ene de la VM povas esti movitaj al disko. Kiel rezulto, la agado de la VM falas ĝis la punkto de frosto. La VM formale funkcias kaj minimume ĝi povas esti konvene malŝaltita de la OS. Se vi estas pacienca 😉
Se VM-oj iris al Ŝanĝi, ĉi tio estas kriz-situacio plej bone evitita se eble.
Bazaj virtualaj maŝinaj memoraj rendimentokalkuliloj
Do ni alvenis al la ĉefa afero. Por kontroli la memoran staton de la VM, ekzistas la sekvaj nombriloj:
aktiva — montras la kvanton da RAM (KB) kiun la VM aliris en la antaŭa mezurperiodo.
uzado — la sama kiel Aktiva, sed kiel procento de la agordita RAM de la VM. Kalkulite uzante la sekvan formulon: aktiva ÷ virtuala maŝino agordita memorgrandeco.
Alta Uzado kaj Aktiva, respektive, ne ĉiam estas indikilo de problemoj de rendimento de VM. Se la VM agreseme uzas memoron (almenaŭ aliras ĝin), tio ne signifas, ke ne ekzistas sufiĉe da memoro. Prefere, ĉi tio estas kialo por rigardi tion, kio okazas en la OS.
Estas norma Alarmo por Memoruzo por VMs:
dividis — la kvanto de VM-RAM deduplikita per TPS (ene de VM aŭ inter VMs).
Koncedita — la kvanto de gastiga fizika memoro (KB) kiu estis asignita al la VM. Ebligas Dividitan.
Konsumita (Koncedita - Kunhavita) - la kvanto de fizika memoro (KB) kiun la VM konsumas de la gastiganto. Ne inkluzivas Shared.
Se parto de la VM-memoro estas donita ne de la fizika memoro de la gastiganto, sed de interŝanĝa dosiero, aŭ memoro estas prenita de la VM per la Balona Ŝoforo, ĉi tiu kvanto ne estas konsiderata en Koncedita kaj Konsumita.
Altaj Konceditaj kaj Konsumitaj valoroj estas tute normalaj. La operaciumo iom post iom prenas memoron de la hiperviziero kaj ne redonas ĝin. Kun la tempo, en aktive funkcianta VM, la valoroj de ĉi tiuj nombriloj alproksimiĝas al la kvanto de agordita memoro, kaj restas tie.
nulo — la kvanto de VM RAM (KB), kiu enhavas nulojn. Tia memoro estas konsiderata libera de la hiperviziero kaj povas esti donita al aliaj virtualaj maŝinoj. Post kiam la gasto OS skribis ion al nuligita memoro, ĝi eniras Consumed kaj ne revenas reen.
Rezervita Supre — la kvanto de VM-RAM, (KB) rezervita de la hiperviziero por operacio de VM. Ĉi tio estas malgranda kvanto, sed ĝi devas esti havebla sur la gastiganto, alie la VM ne komenciĝos.
balono — la kvanto de RAM (KB) forigita de la VM per Balloon Driver.
Kunpremita — la kvanto de RAM (KB) kiu estis kunpremita.
Interŝanĝita — la kvanto de RAM (KB), kiu, pro la manko de fizika memoro en la servilo, movis al disko.
Balonaj kaj aliaj memor-reprenaj teknikoj nombriloj estas nul.
Jen kiel aspektas la grafikaĵo kun la Memoraj nombriloj de normale funkcianta VM kun 150 GB da RAM.
En la suba grafikaĵo, la VM havas evidentajn problemojn. Sub la grafikaĵo vi povas vidi, ke por ĉi tiu VM estis uzataj ĉiuj priskribitaj teknikoj por labori kun RAM. Balono por ĉi tiu VM estas multe pli granda ol Konsumita. Fakte, VM estas pli morta ol viva.
ESXTOP
Kiel ĉe la CPU, se ni volas rapide taksi la situacion sur la gastiganto, same kiel ĝian dinamikon kun intervalo de ĝis 2 sekundoj, ni devus uzi ESXTOP.
La ekrano de la memoro ESXTOP estas alvokita per la klavo "m" kaj aspektas jene (kampoj B,D,H,J,K,L,O elektitaj):
La sekvaj parametroj interesos nin:
Mem overcommit avg — averaĝa valoro de memora troabono ĉe la gastiganto dum 1, 5 kaj 15 minutoj. Se ĝi estas super nulo, tiam ĉi tio estas kialo por rigardi tion, kio okazas, sed ne ĉiam indikilo de problemoj.
En linioj PMEM/MB и VMKMEM/MB — informoj pri la fizika memoro de la servilo kaj la memoro disponebla al la VMkernel. Inter la interesaj aferoj ĉi tie vi povas vidi la minfree valoro (en MB), la gastiga stato en memoro (en nia kazo, alta).
En linio NUMA/MB vi povas vidi la distribuadon de RAM tra NUMA-nodoj (ingoj). En ĉi tiu ekzemplo, la distribuo estas neegala, kio principe ne estas tre bona.
La sekvanta estas ĝeneralaj servilaj statistikoj por memoraj reprenteknikoj:
PSHARE/MB — ĉi tiuj estas TPS-statistikoj;
Interŝanĝi/MB — Interŝanĝu uzado-statistikon;
ZIP/MB — statistikoj pri kunpremado de memorpaĝoj;
MEMCTL/MB — Statistiko pri uzado de Balona Ŝoforo.
Por individuaj VM-oj, ni eble interesiĝas pri la sekvaj informoj. Mi kaŝis la nomojn de la VM-oj por ne konfuzi la publikon :). Se la ESXTOP-metriko similas al la nombrilo en vSphere, mi provizos la respondan nombrilon.
MEMSZ — kvanto de memoro agordita sur la VM (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + netuŝita.
DONU — Koncedita en MB.
TCHD — Aktiva en MBojtoj.
MCTL? — ĉu Balloon Driver estas instalita sur la VM.
MCTLSZ — Balono al MB.
MCTLGT — la kvanto de RAM (MBytes) kiun ESXi volas forigi de la VM per la Balona Ŝoforo (Memctl Target).
MCTLMAX — la maksimuma kvanto de RAM (MBytes) kiun ESXi povas forigi de VM per la Balona Ŝoforo.
SWCUR — la nuna kvanto de RAM (MBytes) asignita al la VM de la Interŝanĝa dosiero.
S.W.G.T. — la kvanto de RAM (MBytes) kiun ESXi volas doni al la VM de la Interŝanĝa dosiero (Swap Target).
Vi ankaŭ povas vidi pli detalajn informojn pri la NUMA-topologio de la VM per ESXTOP. Por fari tion, elektu kampojn D, G:
MALGRANDA – NUMA-nodoj sur kiuj troviĝas la VM. Ĉi tie vi povas tuj rimarki larĝan vm, kiuj ne taŭgas sur unu NUMA-nodo.
NRMEM – kiom da megabajtoj da memoro la VM prenas de la fora NUMA-nodo.
NLMEM – kiom da megabajtoj da memoro la VM prenas de la loka NUMA-nodo.
N%L – procento de VM-memoro sur la loka NUMA-nodo (se malpli ol 80%, povas aperi rendimentoproblemoj).
Memoro sur la hiperviziero
Se CPU-nombriloj por hiperviziero kutime ne estas de speciala intereso, tiam kun memoro la situacio estas la malo. Alta Memoruzo sur VM ne ĉiam indikas rendimentoproblemon, sed alta Memoruzo sur hiperviziero ekigas memoradministradteknikojn kaj kaŭzas problemojn kun VM-efikeco. Vi devas kontroli alarmojn pri Gastiga Memoro-Uzado kaj malhelpi VM-ojn eniri en Ŝanĝi.
Malinterŝanĝi
Se VM estas kaptita en Interŝanĝo, ĝia rendimento estas multe reduktita. Spuroj de Balonado kaj kunpremado rapide malaperas post kiam libera RAM aperas sur la gastiganto, sed la virtuala maŝino ne rapidas reveni de Ŝanĝi al la RAM de la servilo.
Antaŭ ESXi 6.0, la nura fidinda kaj rapida maniero forigi VM de Swap estis rekomenci (pli precize, malŝalti/ŝalti la ujon). Komencante kun ESXi 6.0, kvankam ne tute oficiala, aperis funkcia kaj fidinda maniero forigi VM de Swap. Ĉe unu el la konferencoj, mi povis paroli kun unu el la VMware-inĝenieroj respondecaj pri CPU Scheduler. Li konfirmis, ke la metodo estas sufiĉe funkcia kaj sekura. Laŭ nia sperto, ankaŭ ne estis problemoj kun ĝi.
La realaj komandoj por forigi VM de Ŝanĝi Duncan Epping. Mi ne ripetos la detalan priskribon, mi nur donos ekzemplon pri ĝia uzo. Kiel vi povas vidi en la ekrankopio, iom da tempo post ekzekuto de la specifita komando, Ŝanĝi sur la VM malaperas.
Konsiloj por administri RAM sur ESXi
Fine, jen kelkaj konsiletoj, kiuj helpos vin eviti problemojn kun VM-agado pro RAM:
- Evitu troan abonon de RAM en produktivaj aretoj. Estas konsilinde ĉiam havi ~20-30% da libera memoro en la areto por ke DRS (kaj la administranto) havu spacon por manovri kaj VMs ne iru al Ŝanĝi dum migrado. Ankaŭ, ne forgesu pri la marĝeno por faŭltoleremo. Estas malagrabla kiam, kiam unu servilo malsukcesas kaj la VM estas rekomencita uzante HA, iuj el la maŝinoj ankaŭ iras al Ŝanĝi.
- En tre firmigitaj infrastrukturoj, provu NE krei VM-ojn kun memoro pli granda ol duono de la gastiga memoro. Ĉi tio denove helpos DRS distribui virtualajn maŝinojn tra clusterserviloj sen problemoj. Ĉi tiu regulo, kompreneble, ne estas universala :).
- Atentu pri Gastiga Memoruzo-Uzado-Alarmo.
- Ne forgesu instali VMware Tools sur la VM kaj ne malŝalti Balonadon.
- Konsideru ebligi Inter-VM TPS kaj malŝalti Grandajn Paĝojn en VDI kaj testaj medioj.
- Se la VM spertas rendimentajn problemojn, kontrolu ĉu ĝi uzas memoron de fora NUMA-nodo.
- Forigu VM-ojn de Ŝanĝo kiel eble plej rapide! Interalie, se la VM estas en Interŝanĝo, la stokadsistemo suferas pro evidentaj kialoj.
Tio estas ĉio por mi pri RAM. Malsupre estas rilataj artikoloj por tiuj, kiuj volas profundiĝi. La sekva artikolo estos dediĉita al storaj.
utilaj ligoj
fonto: www.habr.com