Այս հոդվածում մենք կխոսենք vSphere-ում պատահական մուտքի հիշողության (RAM) կատարողականի հաշվիչների մասին:
Թվում է, թե հիշողության դեպքում ամեն ինչ ավելի պարզ է, քան պրոցեսորի դեպքում. եթե VM-ն ունի աշխատանքի հետ կապված խնդիրներ, ապա դժվար է դրանք չնկատել: Բայց եթե դրանք հայտնվեն, շատ ավելի դժվար է նրանց հետ վարվել։ Բայց առաջին հերթին առաջինը:
Մի քիչ տեսություն
Վիրտուալ մեքենաների RAM-ը վերցված է սերվերի հիշողությունից, որի վրա աշխատում են VM-ները: Դա միանգամայն ակնհայտ է :): Եթե սերվերի RAM-ը բավարար չէ բոլորի համար, ESXi-ն սկսում է օգտագործել հիշողության վերականգնման տեխնիկան՝ օպտիմիզացնելու RAM-ի սպառումը: Հակառակ դեպքում, VM օպերացիոն համակարգերը կխափանվեն RAM-ի մուտքի սխալներով:
ESXi-ի օգտագործման ո՞ր տեխնիկան է որոշում՝ կախված RAM-ի ծանրաբեռնվածությունից.
Հիշողության կարգավիճակը
սահման
Գործունեություն
Բարձր
400% minFree
Վերին սահմանին հասնելուց հետո մեծ հիշողության էջերը բաժանվում են փոքրերի (TPS-ն աշխատում է ստանդարտ ռեժիմով):
Մաքրել
100% minFree
Հիշողության մեծ էջերը կոտրվում են փոքրերի, TPS-ը ստիպված է աշխատել:
Փափուկ
64% minFree
TPS + Balloon
Դժվար
32% minFree
TPS + Կոմպրես + Փոխանակում
Ցածր
16% minFree
Սեղմել + Փոխանակել + Արգելափակել
minFree-ը հիպերվիզորի աշխատանքի համար անհրաժեշտ RAM-ն է:
Մինչև ESXi 4.1-ը ներառյալ, minFree-ը լռելյայն ամրագրված էր՝ սերվերի RAM-ի 6%-ը (տոկոսը կարող էր փոխվել ESXi-ի Mem.MinFreePct տարբերակի միջոցով): Հետագա տարբերակներում, սերվերների վրա հիշողության չափերի մեծացման պատճառով, minFree-ն սկսեց հաշվարկվել հոսթ հիշողության քանակի հիման վրա, այլ ոչ թե որպես ֆիքսված տոկոս։
MinFree (կանխադրված) արժեքը հաշվարկվում է հետևյալ կերպ.
MinFree-ի համար պահված հիշողության տոկոսը
Հիշողության տիրույթ
6%
0-4 ԳԲ
4%
4-12 ԳԲ
2%
12-28 ԳԲ
1%
Մնացած հիշողություն
Օրինակ, 128 ԳԲ օպերատիվ հիշողություն ունեցող սերվերի համար MinFree արժեքը կլինի.
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12 ՄԲ = 1,88 ԳԲ
Փաստացի արժեքը կարող է տարբերվել մի քանի հարյուր ՄԲ-ով, դա կախված է սերվերից և RAM-ից:
MinFree-ի համար պահված հիշողության տոկոսը
Հիշողության տիրույթ
Արժեքը 128 ԳԲ-ի համար
6%
0-4 ԳԲ
245,76 ՄԲ
4%
4-12 ԳԲ
327,68 ՄԲ
2%
12-28 ԳԲ
327,68 ՄԲ
1%
Մնացած հիշողություն (100 ԳԲ)
1024 ՄԲ
Սովորաբար, արտադրողական ստենդների համար նորմալ կարելի է համարել միայն Բարձր վիճակը։ Փորձարկման և զարգացման նստարանների համար Մաքուր/Փափուկ վիճակները կարող են ընդունելի լինել: Եթե հոսթի օպերատիվ հիշողությունը 64%-ից պակաս է MinFree-ից, ապա դրա վրա աշխատող VM-ները միանշանակ ունեն աշխատանքի հետ կապված խնդիրներ:
Յուրաքանչյուր վիճակում կիրառվում են հիշողության վերականգնման որոշակի տեխնիկա՝ սկսած TPS-ից, որը գործնականում չի ազդում VM-ի աշխատանքի վրա և վերջացրած Swapping-ով: Ես ձեզ ավելի շատ կասեմ նրանց մասին:
Թափանցիկ էջի փոխանակում (TPS): TPS-ը, կոպիտ ասած, սերվերի վրա վիրտուալ մեքենայի հիշողության էջերի կրկնօրինակումն է:
ESXi-ն փնտրում է վիրտուալ մեքենայի RAM-ի նույնական էջեր՝ հաշվելով և համեմատելով էջերի հեշ գումարը և հեռացնում կրկնօրինակ էջերը՝ դրանք փոխարինելով սերվերի ֆիզիկական հիշողության մեջ նույն էջի հղումներով: Արդյունքում, ֆիզիկական հիշողության սպառումը կրճատվում է, և հիշողության որոշակի գերբաժանորդագրում կարող է իրականացվել կատարողականի նվազման կամ ոչ պակասի դեպքում:
Այս մեխանիզմն աշխատում է միայն 4 ԿԲ հիշողության էջերի համար (փոքր էջեր): Հիպերվիզորը նույնիսկ չի փորձում ջնջել 2 ՄԲ (մեծ էջեր) էջերը. այս չափի նույնական էջեր գտնելու հնարավորությունը մեծ չէ:
Լռելյայնորեն, ESXi-ը հիշողություն է հատկացնում մեծ էջերին: Մեծ էջերը փոքր էջերի բաժանելը սկսվում է, երբ հասնում է Բարձր վիճակի շեմը և պարտադրվում է, երբ հասնում է Clear վիճակին (տես հիպերվիզորի վիճակի աղյուսակը):
Եթե ցանկանում եք, որ TPS-ն սկսի աշխատել առանց սպասելու, որ հյուրընկալող RAM-ը լցվի, ESXi Ընդլայնված ընտրանքներում դուք պետք է սահմանեք արժեքը «Mem.AllocGuestLargePage» մինչև 0 (կանխադրված 1): Այնուհետև վիրտուալ մեքենաների համար մեծ հիշողության էջերի հատկացումը կանջատվի:
2014 թվականի դեկտեմբերից ESXi-ի բոլոր թողարկումներում VM-ների միջև TPS-ը լռելյայն անջատված է, քանի որ հայտնաբերվել է խոցելիություն, որը տեսականորեն թույլ է տալիս մուտք գործել մեկ VM-ից մյուս VM-ի RAM: Մանրամասներն այստեղ։ TPS-ի խոցելիության շահագործման գործնական իրականացման մասին տեղեկատվության չեմ հանդիպել:
TPS քաղաքականությունը վերահսկվում է առաջադեմ տարբերակի միջոցով «Mem.ShareForceSalting» ESXi-ում.
0 - Inter-VM TPS. TPS-ն աշխատում է տարբեր VM-ների էջերի համար;
1 – TPS VM-ի համար նույն «sched.mem.pshare.salt» արժեքով VMX-ում;
2 (լռելյայն) - Intra-VM TPS: TPS-ն աշխատում է VM-ի ներսում գտնվող էջերի համար:
Անկասկած իմաստ ունի անջատել մեծ էջերը և միացնել Inter-VM TPS-ը թեստային նստարաններում: Այն կարող է օգտագործվել նաև նույն տիպի VM-ի մեծ քանակությամբ ստենդների համար: Օրինակ, VDI-ով ստենդների վրա ֆիզիկական հիշողության խնայողությունները կարող են հասնել տասնյակ տոկոսի:
հիշողության փուչիկ. Ballooning-ն այլևս այնքան անվնաս և թափանցիկ տեխնիկա չէ VM օպերացիոն համակարգի համար, ինչպիսին TPS-ն է: Բայց պատշաճ կիրառման դեպքում դուք կարող եք ապրել և նույնիսկ աշխատել Balloning-ով:
Vmware Tools-ի հետ միասին VM-ի վրա տեղադրված է հատուկ դրայվեր, որը կոչվում է Balloon Driver (aka vmmemctl): Երբ հիպերվիզորը սկսում է սպառվել ֆիզիկական հիշողությունից և մտնում է Soft վիճակ, ESXi-ը VM-ին խնդրում է վերականգնել չօգտագործված RAM-ը այս Balloon Driver-ի միջոցով: Վարորդն իր հերթին աշխատում է օպերացիոն համակարգի մակարդակով և պահանջում է ազատ հիշողություն դրանից։ Հիպերվիզորը տեսնում է, թե ֆիզիկական հիշողության որ էջերն է զբաղեցրել Balloon Driver-ը, վերցնում է հիշողությունը վիրտուալ մեքենայից և վերադարձնում հոսթին: ՕՀ-ի շահագործման հետ կապված խնդիրներ չկան, քանի որ OS մակարդակում հիշողությունը զբաղեցնում է Balloon Driver-ը: Լռելյայն Balloon Driver-ը կարող է զբաղեցնել VM հիշողության մինչև 65%-ը:
Եթե VMware Tools-ը տեղադրված չէ VM-ում կամ Balloning-ն անջատված է (խորհուրդ չեմ տալիս, բայց կան. :), հիպերվիզորն անմիջապես անցնում է հիշողության հեռացման ավելի խիստ տեխնիկայի: Եզրակացություն. համոզվեք, որ VMware Tools-ը գտնվում է VM-ում:
Balloon Driver-ի աշխատանքը կարելի է ստուգել ՕՀ-ից VMware Tools-ի միջոցով.
հիշողության սեղմում. Այս տեխնիկան օգտագործվում է, երբ ESXi-ն հասնում է կոշտ վիճակի: Ինչպես անունն է հուշում, ESXi-ն փորձում է փոքրացնել RAM-ի 4 ԿԲ էջը 2 ԿԲ-ի և այդպիսով որոշակի տեղ ազատել սերվերի ֆիզիկական հիշողության վրա: Այս տեխնիկան զգալիորեն մեծացնում է VM RAM էջերի բովանդակության մուտքի ժամանակը, քանի որ էջը նախ պետք է չսեղմվի: Երբեմն ոչ բոլոր էջերը կարող են սեղմվել, և գործընթացն ինքնին որոշակի ժամանակ է պահանջում: Հետեւաբար, այս տեխնիկան գործնականում այնքան էլ արդյունավետ չէ:
հիշողության փոխանակում. Հիշողության սեղմման կարճ փուլից հետո ESXi-ն գրեթե անխուսափելիորեն (եթե VM-ները չեն գնացել այլ հոսթեր կամ անջատվել են) կանցնի Swapping-ի: Իսկ եթե շատ քիչ հիշողություն է մնացել (Low state), ապա հիպերվիզորը դադարում է նաև VM-ին հիշողության էջեր հատկացնել, ինչը կարող է խնդիրներ առաջացնել VM-ի հյուր ՕՀ-ում։
Ահա թե ինչպես է աշխատում Swapping-ը: Երբ միացնում եք վիրտուալ մեքենան, դրա համար ստեղծվում է ֆայլ .vswp ընդլայնմամբ: Այն իր չափերով հավասար է VM-ի չվերապահված RAM-ին. դա կազմաձևված և պահպանված հիշողության տարբերությունն է: Երբ Swapping-ն աշխատում է, ESXi-ն բեռնաթափում է վիրտուալ մեքենայի հիշողության էջերը այս ֆայլի մեջ և սկսում աշխատել դրա հետ սերվերի ֆիզիկական հիշողության փոխարեն: Իհարկե, նման «օպերատիվ» հիշողությունը մի քանի կարգով ավելի դանդաղ է, քան իրականը, նույնիսկ եթե .vswp-ը գտնվում է արագ պահեստավորման վրա:
Ի տարբերություն Balooning-ի, երբ չօգտագործված էջերը վերցվում են VM-ից, Swapping-ով, էջերը, որոնք ակտիվորեն օգտագործվում են ՕՀ-ի կամ VM-ի ներսում հավելվածների կողմից, կարող են տեղափոխվել սկավառակ: Արդյունքում, VM-ի կատարումը իջնում է մինչև սառեցման աստիճան: VM-ը պաշտոնապես աշխատում է, և գոնե այն կարելի է պատշաճ կերպով անջատել ՕՀ-ից: Եթե համբերատար եք 😉
Եթե VM-ները գնացին Swap-ի, սա աննորմալ իրավիճակ է, որից հնարավորության դեպքում լավագույնս խուսափել:
Հիմնական VM հիշողության արդյունավետության հաշվիչներ
Այսպիսով, մենք հասանք հիմնական կետին: VM-ում հիշողության վիճակը վերահսկելու համար կան հետևյալ հաշվիչներ.
ակտիվ — ցույց է տալիս RAM-ի (KB) քանակը, որին հասանելի է եղել VM-ը նախորդ չափման ժամանակահատվածում:
Օգտագործում - նույնը, ինչ Active, բայց որպես VM-ի կազմաձևված RAM-ի տոկոս: Հաշվարկվում է հետևյալ բանաձևով. ակտիվ ÷ վիրտուալ մեքենայի կազմաձևված հիշողության չափը:
Համապատասխանաբար High Usage-ը և Active-ը միշտ չէ, որ VM-ի աշխատանքի հետ կապված խնդիրների ցուցիչ են: Եթե VM-ն ագրեսիվորեն օգտագործում է հիշողությունը (գոնե մուտք է ստանում դրան), դա չի նշանակում, որ հիշողությունը բավարար չէ: Ավելի շուտ առիթ է տեսնելու, թե ինչ է կատարվում ՕՀ-ում։
VM-ների համար կա հիշողության օգտագործման ստանդարտ ահազանգ.
Հղում - VM RAM-ի գումարը, որը հանվել է TPS-ի միջոցով (VM-ի ներսում կամ VM-ների միջև):
Ճիշտ է - ֆիզիկական հյուրընկալող հիշողության քանակը (KB), որը տրվել է VM-ին: Ներառում է Համօգտագործված:
Սպառվում է (տրամադրված - Համօգտագործված) - ֆիզիկական հիշողության (KB) քանակությունը, որը VM-ն սպառում է հոսթից: Չի ներառում Shared-ը:
Եթե VM հիշողության մի մասը տրվում է ոչ թե հյուրընկալողի ֆիզիկական հիշողությունից, այլ փոխանակման ֆայլից, կամ հիշողությունը վերցվում է VM-ից Balloon Driver-ի միջոցով, ապա այդ գումարը հաշվի չի առնվում «Տրված և սպառված» բաժնում:
Բարձր տրված և սպառված արժեքները միանգամայն նորմալ են: Օպերացիոն համակարգը աստիճանաբար վերցնում է հիշողությունը հիպերվիզորից և հետ չի տալիս: Ժամանակի ընթացքում ակտիվորեն աշխատող VM-ում այս հաշվիչների արժեքները մոտենում են կազմաձևված հիշողության քանակին և մնում այնտեղ:
Զրո — VM RAM-ի (KB) քանակը, որը պարունակում է զրոներ: Նման հիշողությունը հիպերվիզորի կողմից համարվում է անվճար և կարող է տրվել այլ վիրտուալ մեքենաների: Այն բանից հետո, երբ հյուր OS-ն ինչ-որ բան գրի զրոյացված հիշողության մեջ, այն մտնում է Consumed և հետ չի վերադառնում:
Վերապահված գլխավերեւում — VM RAM-ի (KB) գումարը, որը վերապահված է հիպերվիզորի կողմից VM-ի շահագործման համար: Սա փոքր գումար է, բայց այն պետք է հասանելի լինի հոսթում, հակառակ դեպքում VM-ն չի գործարկվի:
Փուչիկ — օդապարիկի վարորդի միջոցով VM-ից առգրավված RAM-ի (KB) գումարը:
Սեղմված - սեղմված RAM-ի (KB) քանակը:
Փոխանակված - RAM-ի (KB) քանակությունը, որը սերվերի վրա ֆիզիկական հիշողության բացակայության պատճառով տեղափոխվել է սկավառակ:
Փուչիկների և հիշողության վերականգնման այլ տեխնիկայի հաշվիչները զրո են:
Հիշողության հաշվիչներով գրաֆիկը այսպես է թվում 150 ԳԲ օպերատիվ հիշողությամբ սովորական աշխատող VM-ի համար:
Ստորև բերված գրաֆիկում VM-ն ակնհայտ խնդիրներ ունի: Գրաֆիկի տակ կարող եք տեսնել, որ այս VM-ի համար օգտագործվել են RAM-ի հետ աշխատելու նկարագրված բոլոր տեխնիկաները: Այս VM-ի համար օդապարիկը շատ ավելի մեծ է, քան սպառվածը: Փաստորեն, VM-ն ավելի շատ մեռած է, քան կենդանի:
ESXTOP
Ինչպես պրոցեսորի դեպքում, եթե ցանկանում ենք արագ գնահատել հոսթի իրավիճակը, ինչպես նաև դրա դինամիկան մինչև 2 վայրկյան ընդմիջումով, մենք պետք է օգտագործենք ESXTOP-ը։
Հիշողության ESXTOP էկրանը կանչվում է «m» ստեղնով և ունի հետևյալ տեսքը (ընտրված են B, D, H, J, K, L, O դաշտերը).
Հետևյալ պարամետրերը մեզ կհետաքրքրեն.
Mem overcommit ag - 1, 5 և 15 րոպե հաղորդավարի հիշողության գերբաժանորդագրման միջին արժեքը: Եթե զրոյից բարձր է, ապա սա առիթ է տեսնելու, թե ինչ է կատարվում, բայց ոչ միշտ խնդիրների ցուցիչ։
Տողերում PMEM/MB и VMKMEM/MB - տեղեկատվություն սերվերի ֆիզիկական հիշողության և VMkernel-ին հասանելի հիշողության մասին: Այստեղ հետաքրքիրից կարելի է տեսնել minfree-ի արժեքը (ՄԲ-ով), հիշողության մեջ հոսթի վիճակը (մեր դեպքում՝ բարձր)։
Հերթի մեջ NUMA/MB դուք կարող եք տեսնել RAM-ի բաշխումն ըստ NUMA հանգույցների (վարդակների): Այս օրինակում բաշխումը անհավասար է, ինչը, սկզբունքորեն, այնքան էլ լավ չէ։
Հետևյալը սերվերի ընդհանուր վիճակագրությունն է հիշողության վերականգնման տեխնիկայի վերաբերյալ.
PSHARE/MB են TPS վիճակագրությունը;
SWAP/MB — Փոխանակման օգտագործման վիճակագրություն;
ZIP/MB — հիշողության էջի սեղմման վիճակագրություն;
MEMCTL/MB — Balloon Driver-ի օգտագործման վիճակագրություն:
Առանձին VM-ների համար մեզ կարող է հետաքրքրել հետևյալ տեղեկատվությունը. ՎՄ անունները թաքցրել եմ հանդիսատեսին չշփոթեցնելու համար :)։ Եթե ESXTOP մետրիկը նման է vSphere-ի հաշվիչին, ես տալիս եմ համապատասխան հաշվիչը:
ՄԵՄՍԶ — VM-ում կազմաձևված հիշողության քանակը (MB):
MEMSZ = GRANT + MCTLSZ + SWCUR + untouched.
ԳՐԱՆԹ - Տրվում է ՄԲ-ին:
TCHD — Ակտիվ է ՄԲ-ում:
MCTL? - արդյոք Balloon Driver-ը տեղադրված է VM-ում:
MCTLSZ — Փուչիկ դեպի ՄԲ:
MCTLGT — RAM-ի (ՄԲ) քանակությունը, որը ESXi-ն ցանկանում է վերցնել VM-ից Balloon Driver-ի միջոցով (Memctl Target):
MCTLMAX - RAM-ի առավելագույն քանակը (MB), որը ESXi-ն կարող է վերցնել VM-ից Balloon Driver-ի միջոցով:
SWCUR — Swap ֆայլից VM-ին հատկացված RAM-ի (ՄԲ) ընթացիկ գումարը:
SWGT - RAM-ի (ՄԲ) քանակությունը, որը ESXi-ն ցանկանում է տալ VM-ին Swap ֆայլից (Swap Target):
Նաև ESXTOP-ի միջոցով կարող եք ավելի մանրամասն տեղեկություններ տեսնել VM-ի NUMA տոպոլոգիայի մասին: Դա անելու համար ընտրեք D, G դաշտերը:
ՓՈՔՐ – NUMA հանգույցներ, որոնց վրա գտնվում է VM-ը: Այստեղ դուք կարող եք անմիջապես նկատել լայն vm, որոնք չեն տեղավորվում մեկ NUMA հանգույցի վրա:
NRMEM - քանի մեգաբայթ հիշողություն է վերցնում VM-ը հեռավոր NUMA հանգույցից:
NLMEM - քանի մեգաբայթ հիշողություն է վերցնում VM-ը տեղական NUMA հանգույցից:
N%L – VM հիշողության տոկոսը տեղական NUMA հանգույցում (եթե 80%-ից պակաս է, կարող են առաջանալ աշխատանքի հետ կապված խնդիրներ):
Հիշողություն հիպերվիզորի վրա
Եթե հիպերվիզորի պրոցեսորի հաշվիչները սովորաբար առանձնահատուկ հետաքրքրություն չեն ներկայացնում, ապա հիշողության դեպքում իրավիճակը փոխվում է: VM-ում հիշողության բարձր օգտագործումը միշտ չէ, որ ցույց է տալիս կատարողականի խնդիր, սակայն հիպերվիզորի վրա հիշողության բարձր օգտագործումը գործարկում է հիշողության կառավարման տեխնիկան և առաջացնում է աշխատանքի հետ կապված խնդիրներ VM-ում: Հյուրընկալող հիշողության օգտագործման ահազանգերը պետք է վերահսկվեն՝ VM-ի Swap-ի մուտքը կանխելու համար:
փոխանակել
Եթե VM-ը գտնվում է Swap-ում, նրա կատարումը զգալիորեն նվազում է: Balloning-ի և սեղմման հետքերը արագ անհետանում են այն բանից հետո, երբ հոսթում հայտնվում է անվճար RAM, բայց վիրտուալ մեքենան չի շտապում Swap-ից վերադառնալ սերվերի RAM:
Մինչև ESXi 6.0-ը VM-ին Swap-ից դուրս բերելու միակ հուսալի և արագ միջոցը վերագործարկումն էր (ավելի ճիշտ՝ անջատել/միացնել կոնտեյները): Սկսած ESXi 6.0-ից, թեև ոչ այնքան պաշտոնական, սակայն հայտնվել է VM-ն Swap-ից հեռացնելու աշխատանքային և հուսալի միջոց: Համաժողովներից մեկում ինձ հաջողվեց զրուցել VMware-ի ինժեներներից մեկի հետ, որը պատասխանատու էր CPU Scheduler-ի համար: Նա հաստատեց, որ մեթոդը բավականին աշխատունակ է և անվտանգ։ Մեր փորձով դրա հետ կապված նույնպես խնդիրներ չեն եղել։
Փաստացի հրամանները VM-ը Swap-ից հեռացնելու համար Դունկան Էպինգ. Ես չեմ կրկնի մանրամասն նկարագրությունը, պարզապես բերեմ դրա օգտագործման օրինակ: Ինչպես տեսնում եք սքրինշոթում, նշված հրամանների կատարումից որոշ ժամանակ անց Swap-ը անհետանում է VM-ում:
ESXi հիշողության կառավարման խորհուրդներ
Վերջապես, ահա մի քանի խորհուրդ, որոնք կօգնեն ձեզ խուսափել RAM-ի պատճառով VM-ի աշխատանքի հետ կապված խնդիրներից.
- Խուսափեք հիշողության գերբաժանորդագրումից արդյունավետ կլաստերներում: Ցանկալի է կլաստերում միշտ ունենալ ~20-30% ազատ հիշողություն, որպեսզի DRS-ը (և ադմինիստրատորը) մանևրելու տեղ ունենան, իսկ VM-ները միգրացիայի ժամանակ չմտնեն Swap-ի։ Նաև մի մոռացեք սխալների հանդուրժողականության սահմանի մասին: Տհաճ է, երբ, երբ մեկ սերվերը ձախողվում է, և VM-ը վերագործարկվում է HA-ի միջոցով, որոշ մեքենաներ նույնպես անցնում են Swap-ի:
- Խիստ համախմբված ենթակառուցվածքներում փորձեք ՉԻ ստեղծել VM-ներ հյուրընկալող հիշողության կեսից ավելիով: Սա կրկին կօգնի DRS-ին առանց որևէ խնդիրների բաշխել վիրտուալ մեքենաները կլաստերային սերվերների վրա: Այս կանոնը, իհարկե, ունիվերսալ չէ :)։
- Դիտեք հյուրընկալող հիշողության օգտագործման ահազանգը:
- Մի մոռացեք տեղադրել VMware Tools-ը VM-ի վրա և մի անջատեք Balloning-ը:
- Մտածեք միացնել Inter-VM TPS-ը և անջատել Մեծ էջերը VDI-ում և թեստային միջավայրերում:
- Եթե VM-ն աշխատանքի հետ կապված խնդիրներ ունի, ստուգեք՝ արդյոք այն օգտագործում է հիշողություն հեռավոր NUMA հանգույցից:
- Հնարավորինս արագ դուրս բերեք ձեր VM-ին Swap-ից: Ի թիվս այլ բաների, եթե VM-ը Swap-ում է, հասկանալի պատճառներով, պահեստավորման համակարգը տուժում է:
Ինձ համար այսքանն է RAM-ի մասին: Ստորև բերված է համապատասխան հոդված նրանց համար, ովքեր ցանկանում են խորանալ մանրամասների մեջ: Հաջորդ հոդվածը նվիրված կլինի storadzh-ին։
Օգտակար հղումներ
Source: www.habr.com