Եթե դուք կառավարում եք վիրտուալ ենթակառուցվածք, որը հիմնված է VMware vSphere-ի (կամ ցանկացած այլ տեխնոլոգիական ստեկի) վրա, հավանաբար հաճախ եք լսում օգտատերերի բողոքները. «Վիրտուալ մեքենան դանդաղ է աշխատում»: Այս հոդվածների շարքում ես կվերլուծեմ կատարողականի ցուցանիշները և կպատմեմ ձեզ, թե ինչ և ինչու է այն դանդաղում և ինչպես համոզվել, որ այն չի դանդաղում:
Ես կքննարկեմ վիրտուալ մեքենայի կատարման հետևյալ ասպեկտները.
- Պրոցեսոր,
- RAM,
- ՍԿՍԱՎՈՐ,
- Անց:
Ես կսկսեմ պրոցեսորից:
Կատարումը վերլուծելու համար մեզ անհրաժեշտ կլինի.
- vCenter Performance Հաշվիչներ – կատարողականի հաշվիչներ, որոնց գրաֆիկները կարելի է դիտել vSphere Client-ի միջոցով: Այս հաշվիչների վերաբերյալ տեղեկատվությունը հասանելի է հաճախորդի ցանկացած տարբերակում («հաստ» հաճախորդ C#-ում, վեբ հաճախորդ՝ Flex-ում և վեբ հաճախորդ՝ HTML5): Այս հոդվածներում մենք կօգտագործենք C# հաճախորդի սքրինշոթները, միայն այն պատճառով, որ դրանք ավելի լավ տեսք ունեն մանրանկարչության մեջ :)
- ESXTOP – կոմունալ ծրագիր, որն աշխատում է ESXi հրամանի տողից: Նրա օգնությամբ դուք կարող եք իրական ժամանակում ստանալ կատարողականի հաշվիչների արժեքները կամ վերբեռնել այդ արժեքները որոշակի ժամանակահատվածում .csv ֆայլ՝ հետագա վերլուծության համար: Հաջորդը, ես ձեզ ավելին կպատմեմ այս գործիքի մասին և մի քանի օգտակար հղումներ կներկայացնեմ թեմայի վերաբերյալ փաստաթղթերին և հոդվածներին:
Մի քիչ տեսություն
ESXi-ում առանձին գործընթաց՝ VMware տերմինաբանության աշխարհը, պատասխանատու է յուրաքանչյուր vCPU-ի (վիրտուալ մեքենայի միջուկ) աշխատանքի համար: Կան նաև սպասարկման գործընթացներ, բայց VM-ի կատարողականի վերլուծության տեսանկյունից դրանք ավելի քիչ հետաքրքիր են։
ESXi-ում գործընթացը կարող է լինել չորս վիճակներից մեկում.
- Վազում – գործընթացը կատարում է որոշ օգտակար աշխատանք:
- Սպասեք: – գործընթացը որևէ աշխատանք չի կատարում (անգործուն) կամ սպասում է մուտքի/ելքի:
- Կոստոպ – պայման, որը տեղի է ունենում բազմամիջուկ վիրտուալ մեքենաներում: Դա տեղի է ունենում, երբ հիպերվիզորի պրոցեսորի ժամանակացույցը (ESXi CPU Scheduler) չի կարող պլանավորել բոլոր ակտիվ վիրտուալ մեքենայի միջուկների միաժամանակյա կատարումը ֆիզիկական սերվերի միջուկների վրա: Ֆիզիկական աշխարհում բոլոր պրոցեսորային միջուկները աշխատում են զուգահեռ, VM-ի ներսում գտնվող հյուր ՕՀ-ն ակնկալում է նմանատիպ վարքագիծ, ուստի հիպերվիզորը պետք է դանդաղեցնի VM միջուկները, որոնք կարող են ավելի արագ ավարտել իրենց ժամացույցը: ESXi-ի ժամանակակից տարբերակներում պրոցեսորի ժամանակացույցն օգտագործում է մի մեխանիզմ, որը կոչվում է հանգիստ համաժամանակացում. հիպերվիզորը հաշվի է առնում «ամենաարագ» և «ամենադանդաղ» վիրտուալ մեքենայի միջուկի (թեք) միջև եղած բացը: Եթե բացը գերազանցում է որոշակի շեմը, արագ միջուկը մտնում է ծախսային վիճակ: Եթե VM միջուկները շատ ժամանակ են ծախսում այս վիճակում, դա կարող է առաջացնել աշխատանքի հետ կապված խնդիրներ:
- Պատրաստ – գործընթացը մտնում է այս վիճակի մեջ, երբ հիպերվիզորը չի կարողանում ռեսուրսներ հատկացնել դրա կատարման համար: Պատրաստի բարձր արժեքները կարող են VM-ի աշխատանքի հետ կապված խնդիրներ առաջացնել:
Հիմնական վիրտուալ մեքենայի պրոցեսորի աշխատանքի հաշվիչներ
CPU-ի օգտագործում, %. Ցույց է տալիս տվյալ ժամանակահատվածի համար պրոցեսորի օգտագործման տոկոսը:
Ինչպե՞ս վերլուծել: Եթե VM-ը հետևողականորեն օգտագործում է պրոցեսորը 90%-ով կամ գագաթնակետերը մինչև 100%, ապա մենք խնդիրներ ունենք: Խնդիրները կարող են արտահայտվել ոչ միայն VM-ի ներսում հավելվածի «դանդաղ» գործողության մեջ, այլ նաև ցանցի միջոցով VM-ի անհասանելիության մեջ: Եթե մոնիտորինգի համակարգը ցույց է տալիս, որ VM-ը պարբերաբար ընկնում է, ուշադրություն դարձրեք CPU Usage գրաֆիկի գագաթնակետին:
Կա ստանդարտ ահազանգ, որը ցույց է տալիս վիրտուալ մեքենայի պրոցեսորի ծանրաբեռնվածությունը.
Ինչ անել? Եթե VM-ի CPU-ի օգտագործումը անընդհատ անցնում է տանիքի միջով, ապա կարող եք մտածել vCPU-ների քանակի ավելացման մասին (ցավոք, դա միշտ չէ, որ օգնում է) կամ VM-ն ավելի հզոր պրոցեսորներով սերվեր տեղափոխելու մասին:
CPU-ի օգտագործումը ՄՀց-ում
vCenter Usage-ի գծապատկերներում %-ով դուք կարող եք տեսնել միայն ամբողջ վիրտուալ մեքենայի համար, առանձին միջուկների համար գծապատկերներ չկան (Esxtop-ում կան % արժեքներ միջուկների համար): Յուրաքանչյուր միջուկի համար կարող եք տեսնել Օգտագործումը ՄՀց-ով:
Ինչպե՞ս վերլուծել: Պատահում է, որ հավելվածը օպտիմիզացված չէ բազմամիջուկ ճարտարապետության համար. այն օգտագործում է միայն մեկ միջուկ 100%, իսկ մնացածը պարապ են առանց բեռնվածության: Օրինակ, լռելյայն կրկնօրինակման կարգավորումներով, MS SQL-ը սկսում է գործընթացը միայն մեկ միջուկի վրա: Արդյունքում, կրկնօրինակումը դանդաղում է ոչ թե սկավառակների դանդաղ արագության պատճառով (սա այն է, ինչի մասին սկզբում դժգոհում էր օգտվողը), այլ այն պատճառով, որ պրոցեսորը չի կարողանում հաղթահարել: Խնդիրը լուծվեց՝ փոխելով պարամետրերը. կրկնօրինակումը սկսեց զուգահեռ աշխատել մի քանի ֆայլերում (համապատասխանաբար՝ մի քանի գործընթացներում):
Միջուկների վրա անհավասար բեռի օրինակ:
Կա նաև մի իրավիճակ (ինչպես վերը նշված գրաֆիկում), երբ միջուկները բեռնված են անհավասարաչափ, և դրանցից ոմանք ունեն 100% գագաթներ: Ինչպես միայն մեկ միջուկ բեռնելու դեպքում, CPU Usage-ի տագնապը չի աշխատի (դա ամբողջ VM-ի համար է), բայց կլինեն աշխատանքի հետ կապված խնդիրներ:
Ինչ անել? Եթե վիրտուալ մեքենայի ծրագրակազմը բեռնում է միջուկները անհավասարաչափ (օգտագործում է միայն մեկ միջուկ կամ միջուկների մի մասը), իմաստ չունի ավելացնել դրանց թիվը: Այս դեպքում ավելի լավ է VM-ը տեղափոխել ավելի հզոր պրոցեսորներով սերվեր:
Կարող եք նաև փորձել ստուգել էներգիայի սպառման կարգավորումները սերվերի BIOS-ում: Շատ ադմինիստրատորներ BIOS-ում միացնում են High Performance ռեժիմը և դրանով իսկ անջատում C-states և P-states էներգախնայողության տեխնոլոգիաները: Ժամանակակից Intel պրոցեսորներն օգտագործում են Turbo Boost տեխնոլոգիան, որը մեծացնում է առանձին պրոցեսորային միջուկների հաճախականությունը՝ ի հաշիվ այլ միջուկների։ Բայց այն աշխատում է միայն այն դեպքում, երբ միացված են էներգախնայողության տեխնոլոգիաները: Եթե դրանք անջատենք, պրոցեսորը չի կարող նվազեցնել բեռնված միջուկների էներգիայի սպառումը:
VMware-ը խորհուրդ է տալիս չանջատել էներգախնայողության տեխնոլոգիաները սերվերների վրա, այլ ընտրել այնպիսի ռեժիմներ, որոնք հնարավորինս թողնում են էներգիայի կառավարումը հիպերվիզորին։ Այս դեպքում հիպերվիզորի էներգիայի սպառման կարգավորումներում դուք պետք է ընտրեք Բարձր կատարողականություն:
Եթե ձեր ենթակառուցվածքում ունեք անհատական VM-ներ (կամ VM միջուկներ), որոնք պահանջում են պրոցեսորի հաճախականության բարձրացում, էներգիայի սպառման ճիշտ կարգավորումը կարող է զգալիորեն բարելավել դրանց աշխատանքը:
CPU-ն պատրաստ է
Եթե VM միջուկը (vCPU) գտնվում է Ready վիճակում, այն օգտակար աշխատանք չի կատարում: Այս պայմանը տեղի է ունենում, երբ հիպերվիզորը չի գտնում ազատ ֆիզիկական միջուկ, որին կարող է վերագրվել վիրտուալ մեքենայի vCPU գործընթացը:
Ինչպե՞ս վերլուծել: Սովորաբար, եթե վիրտուալ մեքենայի միջուկները 10%-ից ավելի ժամանակի պատրաստ վիճակում են, դուք կնկատեք աշխատանքի հետ կապված խնդիրներ: Պարզ ասած, ավելի քան 10% ժամանակի VM-ը սպասում է ֆիզիկական ռեսուրսների հասանելիությանը:
vCenter-ում կարող եք դիտել CPU Ready-ի հետ կապված 2 հաշվիչ.
- պատրաստակամություն,
- Պատրաստ է:
Երկու հաշվիչների արժեքները կարող են դիտվել ինչպես ամբողջ VM-ի, այնպես էլ առանձին միջուկների համար:
Պատրաստությունը ցույց է տալիս արժեքը անմիջապես որպես տոկոս, բայց միայն իրական ժամանակում (վերջին ժամի տվյալները, չափման միջակայքը 20 վայրկյան): Ավելի լավ է այս հաշվիչն օգտագործել միայն «կրունկների վրա տաք» խնդիրներ փնտրելու համար:
Պատրաստի հակաարժեքները կարող են դիտվել նաև պատմական տեսանկյունից: Սա օգտակար է օրինաչափություններ հաստատելու և խնդրի ավելի խորը վերլուծության համար: Օրինակ, եթե վիրտուալ մեքենան որոշակի ժամանակ սկսում է աշխատանքի հետ կապված խնդիրներ ունենալ, կարող եք համեմատել CPU Ready արժեքի միջակայքերը սերվերի ընդհանուր բեռնվածության հետ, որտեղ աշխատում է այս VM-ը, և միջոցներ ձեռնարկել բեռնվածությունը նվազեցնելու համար (եթե DRS ձախողվում է):
Ready-ը, ի տարբերություն Readiness-ի, ցուցադրվում է ոչ թե տոկոսներով, այլ միլիվայրկյաններով։ Սա Sumation տիպի հաշվիչ է, այսինքն՝ ցույց է տալիս, թե որքան ժամանակ է եղել VM միջուկը չափման ժամանակահատվածում Ready վիճակում։ Դուք կարող եք այս արժեքը վերածել տոկոսի՝ օգտագործելով պարզ բանաձևը.
(CPU պատրաստի ամփոփման արժեք / (գծապատկերի լռելյայն թարմացման միջակայքը վայրկյաններով * 1000)) * 100 = CPU պատրաստ %
Օրինակ, ստորև բերված գրաֆիկում VM-ի համար գագաթնակետային Ready արժեքը ամբողջ վիրտուալ մեքենայի համար կլինի հետևյալը.
Պատրաստի տոկոսը հաշվարկելիս պետք է ուշադրություն դարձնել երկու կետի.
- Ամբողջ VM-ի համար Ready արժեքը միջուկների միջև Ready-ի գումարն է:
- Չափման միջակայքը. Իրական ժամանակի համար դա 20 վայրկյան է, իսկ, օրինակ, ամենօրյա գծապատկերներում՝ 300 վայրկյան։
Ակտիվ անսարքությունների վերացման դեպքում այս պարզ կետերը հեշտությամբ կարելի է բաց թողնել, և արժեքավոր ժամանակը կարող է վատնվել գոյություն չունեցող խնդիրների լուծման վրա:
Եկեք հաշվարկենք Ready-ը ստորև բերված գրաֆիկի տվյալների հիման վրա: (324474/(20*1000))*100 = 1622% ամբողջ VM-ի համար: Եթե նայեք միջուկներին, այնքան էլ սարսափելի չէ՝ 1622 թ/64 = 25% մեկ միջուկի համար: Այս դեպքում բռնումը բավականին հեշտ է նկատել. Ready արժեքը անիրատեսական է: Բայց եթե մենք խոսում ենք 10-20% ամբողջ VM-ի համար մի քանի միջուկներով, ապա յուրաքանչյուր միջուկի համար արժեքը կարող է լինել նորմալ միջակայքում:
Ինչ անել? Ready բարձր արժեքը ցույց է տալիս, որ սերվերը չունի բավարար պրոցեսորային ռեսուրսներ վիրտուալ մեքենաների բնականոն աշխատանքի համար: Նման իրավիճակում մնում է նվազեցնել պրոցեսորի կողմից գերաբաժանորդագրումը (vCPU:pCPU): Ակնհայտ է, որ դրան կարելի է հասնել՝ նվազեցնելով առկա VM-ների պարամետրերը կամ VM-ների մի մասը տեղափոխելով այլ սերվերներ:
Co-stop
Ինչպե՞ս վերլուծել: Այս հաշվիչը նույնպես Գումարի տիպի է և փոխարկվում է տոկոսների այնպես, ինչպես Ready:
(CPU co-stop գումարման արժեք / (գծապատկերի լռելյայն թարմացման միջակայքը վայրկյաններով * 1000)) * 100 = CPU co-stop %
Այստեղ դուք նույնպես պետք է ուշադրություն դարձնեք VM-ի միջուկների քանակին և չափման միջակայքին:
Costop վիճակում միջուկը օգտակար աշխատանք չի կատարում։ VM-ի չափի և սերվերի վրա նորմալ բեռնվածության ճիշտ ընտրության դեպքում «co-stop» հաշվիչը պետք է մոտ լինի զրոյին:
Այս դեպքում ծանրաբեռնվածությունը ակնհայտորեն աննորմալ է :)
Ինչ անել? Եթե մեծ թվով միջուկներով մի քանի VM-ներ աշխատում են մեկ հիպերվիզորի վրա, և պրոցեսորի վրա գերբաժանորդագրում կա, ապա co-stop հաշվիչը կարող է մեծանալ, ինչը կհանգեցնի այս VM-ների աշխատանքի հետ կապված խնդիրների:
Բացի այդ, co-stop-ը կավելանա, եթե մեկ VM-ի ակտիվ միջուկները օգտագործեն շղթաներ մեկ ֆիզիկական սերվերի միջուկի վրա, որի գործառույթը միացված է հիպերտրադինգը: Այս իրավիճակը կարող է առաջանալ, օրինակ, եթե VM-ն ունի ավելի շատ միջուկներ, քան ֆիզիկապես հասանելի է սերվերում, որտեղ այն աշխատում է, կամ եթե «preferHT» պարամետրը միացված է VM-ի համար: Դուք կարող եք կարդալ այս պարամետրի մասին .
VM-ի աշխատանքի հետ կապված խնդիրներից խուսափելու համար՝ բարձր համատեղ կանգառի պատճառով, ընտրեք VM-ի չափը՝ համաձայն այս VM-ի վրա աշխատող ծրագրաշարի արտադրողի առաջարկություններին և ֆիզիկական սերվերի հնարավորություններին, որտեղ աշխատում է VM-ը:
Մի ավելացրեք միջուկներ ռեզերվում, դա կարող է աշխատանքի հետ կապված խնդիրներ առաջացնել ոչ միայն բուն VM-ի, այլև սերվերի նրա հարևանների համար:
Այլ օգտակար CPU չափումներ
Վազում – որքան ժամանակ (մս) չափման ժամանակահատվածում vCPU-ն գտնվել է RUN վիճակում, այսինքն՝ իրականում օգտակար աշխատանք է կատարել:
պարապ – որքան ժամանակ (մս) է եղել vCPU-ն չափման ժամանակահատվածում անգործության վիճակում: Idle-ի բարձր արժեքները խնդիր չեն, vCPU-ն պարզապես «անելու բան չուներ»:
Սպասեք: – որքան ժամանակ (մս) է եղել vCPU-ն չափման ժամանակահատվածում սպասման վիճակում: Քանի որ IDLE-ն ներառված է այս հաշվիչում, սպասման բարձր արժեքները նույնպես խնդիր չեն ցույց տալիս: Բայց եթե Wait IDLE-ը ցածր է, երբ սպասումը բարձր է, դա նշանակում է, որ VM-ն սպասում էր I/O գործողությունների ավարտին, և դա, իր հերթին, կարող է ցույց տալ խնդիր կոշտ սկավառակի կամ VM-ի ցանկացած վիրտուալ սարքի աշխատանքի հետ:
Առավելագույնը սահմանափակ է – որքան ժամանակ (մս) չափման ժամանակահատվածում vCPU-ն եղել է պատրաստ վիճակում՝ պայմանավորված ռեսուրսների սահմանված սահմանաչափով: Եթե կատարումը անհասկանալիորեն ցածր է, ապա օգտակար է ստուգել այս հաշվիչի արժեքը և պրոցեսորի սահմանաչափը VM-ի կարգավորումներում: VM-ները իսկապես կարող են սահմաններ ունենալ, որոնց մասին դուք տեղյակ չեք: Օրինակ, դա տեղի է ունենում, երբ VM-ը կլոնավորվել է կաղապարից, որի վրա դրվել է CPU-ի սահմանաչափը:
Փոխանակում սպասել – որքան ժամանակ է vCPU-ն սպասել չափման ժամանակահատվածում VMkernel Swap-ով գործողության: Եթե այս հաշվիչի արժեքները զրոյից բարձր են, ապա VM-ն միանշանակ ունի աշխատանքի հետ կապված խնդիրներ: SWAP-ի մասին ավելին կխոսենք RAM հաշվիչների մասին հոդվածում:
ESXTOP
Եթե vCenter-ում կատարողականի հաշվիչները լավ են պատմական տվյալները վերլուծելու համար, ապա խնդրի գործառնական վերլուծությունը ավելի լավ է անել ESXTOP-ում: Այստեղ բոլոր արժեքները ներկայացված են պատրաստի տեսքով (ոչինչ թարգմանելու կարիք չկա), իսկ նվազագույն չափման ժամկետը 2 վայրկյան է։
CPU-ի համար ESXTOP էկրանը կանչվում է «c» ստեղնով և ունի հետևյալ տեսքը.
Հարմարության համար կարող եք թողնել միայն վիրտուալ մեքենայի գործընթացները՝ սեղմելով Shift-V:
Առանձին VM միջուկների չափումները դիտելու համար սեղմեք «e» և մուտքագրեք հետաքրքրություն ներկայացնող VM-ի GID-ը (30919 ստորև ներկայացված սքրինշոթում).
Թույլ տվեք համառոտ անցնել լռելյայն ներկայացված սյունակներին։ Լրացուցիչ սյունակներ կարող են ավելացվել՝ սեղմելով «f»:
NWLD (Աշխարհների թիվը) - խմբում գործընթացների քանակը: Խումբը ընդլայնելու և յուրաքանչյուր գործընթացի համար չափումներ տեսնելու համար (օրինակ՝ բազմամիջուկ VM-ի յուրաքանչյուր միջուկի համար), սեղմեք «e»: Եթե խմբում կա մեկից ավելի գործընթաց, ապա խմբի համար մետրային արժեքները հավասար են առանձին գործընթացների չափումների գումարին:
ՕԳՏԱԳՈՐԾՎԱԾ – քանի սերվերի պրոցեսորի ցիկլ է օգտագործվում գործընթացի կամ գործընթացների խմբի կողմից:
RUN – որքան ժամանակ է եղել չափման ժամանակահատվածում գործընթացը RUN վիճակում, այսինքն. օգտակար աշխատանք է կատարել. Այն տարբերվում է %USED-ից նրանով, որ հաշվի չի առնում հիպերթելավորումը, հաճախականության մասշտաբը և համակարգի առաջադրանքների վրա ծախսված ժամանակը (%SYS):
%SYS – Համակարգի առաջադրանքների վրա ծախսված ժամանակը, օրինակ՝ ընդհատումների մշակում, մուտք/ելք, ցանցի շահագործում և այլն: Արժեքը կարող է բարձր լինել, եթե VM-ն ունի մեծ I/O:
%OVRLP – որքա՞ն ժամանակ է ծախսել ֆիզիկական միջուկը, որի վրա աշխատում է VM գործընթացը, այլ գործընթացների առաջադրանքների վրա:
Այս ցուցանիշները միմյանց հետ կապված են հետևյալ կերպ.
%USED = %RUN + %SYS - %OVRLP:
Սովորաբար %USED չափիչն ավելի տեղեկատվական է:
ՍՊԱՍԵԼ – որքան ժամանակ է եղել չափման ժամանակահատվածում գործընթացը սպասման վիճակում: Միացնում է IDLE-ն:
%ՊԱՐՈՒՆ – որքա՞ն ժամանակ է եղել չափման ժամանակաշրջանում գործընթացը անգործուն վիճակում:
%SWPWT – որքան ժամանակ է vCPU-ն սպասել չափման ժամանակահատվածում VMkernel Swap-ով գործողության:
%VMWAIT – որքա՞ն ժամանակ է եղել չափման ժամանակահատվածում vCPU-ն իրադարձության սպասման վիճակում (սովորաբար I/O): vCenter-ում նմանատիպ հաշվիչ չկա: Բարձր արժեքները ցույց են տալիս VM-ում I/O-ի հետ կապված խնդիրներ:
%WAIT = %VMWAIT + %IDLE + %SWPWT:
Եթե VM-ը չի օգտագործում VMkernel Swap-ը, ապա աշխատանքի հետ կապված խնդիրները վերլուծելիս խորհուրդ է տրվում նայել %VMWAIT-ին, քանի որ այս ցուցանիշը հաշվի չի առնում այն ժամանակը, երբ VM-ն ոչինչ չէր անում (%IDLE):
%RDY – որքան ժամանակ է եղել չափման ժամանակահատվածում գործընթացը պատրաստ վիճակում:
%CSTP - չափման ժամանակահատվածում որքան ժամանակ է եղել գործընթացը ծախսային վիճակում:
%MLMTD – որքան ժամանակ է եղել չափման ժամանակահատվածում vCPU-ն պատրաստ վիճակում՝ պայմանավորված ռեսուրսների սահմանված սահմանաչափով:
%WAIT + %RDY + %CSTP + %RUN = 100% – VM միջուկը միշտ գտնվում է այս չորս վիճակներից մեկում:
CPU հիպերվիզորի վրա
vCenter-ն ունի նաև պրոցեսորի աշխատանքի հաշվիչներ հիպերվիզորի համար, բայց դրանք ոչ մի հետաքրքիր բան չեն. դրանք պարզապես սերվերի բոլոր VM-ների հաշվիչների գումարն են:
Սերվերում պրոցեսորի կարգավիճակը դիտելու ամենահարմար միջոցը Ամփոփում ներդիրում է՝
Սերվերի, ինչպես նաև վիրտուալ մեքենայի համար կա ստանդարտ ահազանգ.
Երբ սերվերի պրոցեսորի ծանրաբեռնվածությունը մեծ է, դրա վրա աշխատող VM-ները սկսում են աշխատանքի հետ կապված խնդիրներ ունենալ:
ESXTOP-ում սերվերի պրոցեսորի բեռնվածության տվյալները ներկայացված են էկրանի վերևում: Ի լրումն ստանդարտ պրոցեսորի բեռնվածության, որը հիպերվիզորների համար այնքան էլ տեղեկատվական չէ, կան ևս երեք չափումներ.
CORE UTIL (%) - ֆիզիկական սերվերի միջուկի բեռնում: Այս հաշվիչը ցույց է տալիս, թե որքան ժամանակ է միջուկը կատարել աշխատանքը չափման ժամանակահատվածում:
PCPU UTIL (%) – եթե Hyper-threading-ը միացված է, ապա յուրաքանչյուր ֆիզիկական միջուկում կա երկու շարանը (PCPU): Այս ցուցանիշը ցույց է տալիս, թե որքան ժամանակ է պահանջվել յուրաքանչյուր շղթայի աշխատանքը ավարտելու համար:
PCPU ՕԳՏԱԳՈՐԾՎԱԾ (%) – նույնը, ինչ PCPU UTIL (%), բայց հաշվի է առնում հաճախականության մասշտաբը (կամ նվազեցնելով հիմնական հաճախականությունը էներգախնայողության նպատակներով, կամ մեծացնելով հիմնական հաճախականությունը Turbo Boost տեխնոլոգիայի շնորհիվ) և հիպերթրեյդինգը:
PCPU_USED% = PCPU_UTIL% * արդյունավետ հիմնական հաճախականություն / անվանական հիմնական հաճախականություն:
Այս սքրինշոթում որոշ միջուկների համար Turbo Boost-ի շնորհիվ USED արժեքը 100%-ից ավելի է, քանի որ հիմնական հաճախականությունը ավելի բարձր է, քան անվանականը:
Մի քանի խոսք այն մասին, թե ինչպես է հաշվի առնվում հիպերթելինգը։ Եթե գործընթացները կատարվում են ժամանակի 100%-ով սերվերի ֆիզիկական միջուկի երկու թելերի վրա, մինչդեռ միջուկը գործում է անվանական հաճախականությամբ, ապա.
- CORE UTIL միջուկի համար կլինի 100%,
- PCPU UTIL երկու թելերի համար կլինի 100%,
- Երկու թելերի համար օգտագործվող PCPU-ն կկազմի 50%:
Եթե չափման ժամանակաշրջանում երկու թելերն էլ ժամանակի 100%-ով չեն աշխատել, ապա այդ ժամանակահատվածներում, երբ թելերը զուգահեռ աշխատել են, միջուկների համար օգտագործվող PCPU-ն կիսով չափ կիսվում է:
ESXTOP-ն ունի նաև էկրան՝ սերվերի պրոցեսորի էներգիայի սպառման պարամետրերով: Այստեղ դուք կարող եք տեսնել, թե արդյոք սերվերն օգտագործում է էներգախնայողության տեխնոլոգիաներ՝ C-states և P-states: Զանգված է «p» ստեղնով.
CPU-ի աշխատանքի ընդհանուր խնդիրներ
Վերջապես, ես կանդրադառնամ VM CPU-ի աշխատանքի հետ կապված խնդիրների բնորոշ պատճառներին և կարճ խորհուրդներ կտամ դրանք լուծելու համար.
Հիմնական ժամացույցի արագությունը բավարար չէ: Եթե հնարավոր չէ թարմացնել ձեր VM-ն ավելի հզոր միջուկների, կարող եք փորձել փոխել էներգիայի կարգավորումները՝ Turbo Boost-ն ավելի արդյունավետ աշխատելու համար:
VM-ի սխալ չափագրում (չափազանց շատ/քիչ միջուկներ): Եթե տեղադրեք մի քանի միջուկներ, VM-ի վրա պրոցեսորի մեծ բեռ կլինի: Եթե շատ կա, բռնեք բարձր համակցված կանգառ:
Սերվերի վրա պրոցեսորի մեծ գերբաժանորդագրում: Եթե VM-ն ունի բարձր Ready, նվազեցրեք պրոցեսորի գերբաժանորդագրումը:
Սխալ NUMA տոպոլոգիա խոշոր VM-ների վրա: VM-ի կողմից տեսած NUMA տոպոլոգիան (vNUMA) պետք է համընկնի սերվերի NUMA տոպոլոգիայի հետ (pNUMA): Այս խնդրի ախտորոշումը և հնարավոր լուծումները գրված են, օրինակ, գրքում . Եթե դուք չեք ցանկանում ավելի խորանալ, և դուք չունեք լիցենզավորման սահմանափակումներ VM-ում տեղադրված ՕՀ-ի վրա, ապա VM-ում ստեղծեք բազմաթիվ վիրտուալ վարդակներ՝ մեկ միջուկ: Շատ բան չես կորցնի :)
Ինձ համար այսքանը CPU-ի մասին է: Հարցեր տալ. Հաջորդ մասում ես կխոսեմ RAM-ի մասին:
Օգտակար հղումներ
Source: www.habr.com