Գողանալ. ով է գողանում պրոցեսորի ժամանակը վիրտուալ մեքենաներից

Բարեւ Ձեզ! Ես ուզում եմ պարզ բառերով պատմել վիրտուալ մեքենաների ներսում գողության առաջացման մեխանիզմի և որոշ ոչ ակնհայտ արտեֆակտների մասին, որոնք մեզ հաջողվել է պարզել նրա հետազոտության ընթացքում, որոնք ես ստիպված էի սուզվել որպես ամպային հարթակի տեխնիկական տնօրեն: Mail.ru Cloud Solutions. Պլատֆորմն աշխատում է KVM-ով:

CPU-ի հափշտակման ժամանակը այն ժամանակն է, որի ընթացքում վիրտուալ մեքենան չի ստանում պրոցեսորային ռեսուրսներ իր կատարման համար: Այս ժամանակը դիտարկվում է միայն հյուրի օպերացիոն համակարգերում վիրտուալացման միջավայրերում: Պատճառները, թե ուր են գնում այդ հատկացված միջոցները, ինչպես կյանքում, շատ անորոշ են։ Բայց մենք որոշեցինք դա պարզել, նույնիսկ մի շարք փորձեր կազմակերպեցինք: Այնպես չէ, որ մենք հիմա ամեն ինչ գիտենք գողության մասին, բայց հիմա ձեզ մի հետաքրքիր բան կասենք:

1. Ինչ է գողությունը

Այսպիսով, գողությունը չափիչ է, որը ցույց է տալիս վիրտուալ մեքենայի ներսում պրոցեսների համար պրոցեսորի ժամանակի բացակայությունը: Ինչպես նկարագրված է KVM միջուկի կարկատում, գողանալը այն ժամանակն է, երբ հիպերվիզորը կատարում է այլ գործընթացներ հյուրընկալող ՕՀ-ում, չնայած այն հերթագրել է վիրտուալ մեքենայի գործընթացը կատարման համար: Այսինքն՝ գողանալը հաշվարկվում է որպես պրոցեսի գործարկման պատրաստ ժամանակի և պրոցեսին CPU-ի ժամանակ հատկացնելու ժամանակի տարբերություն:

Վիրտուալ մեքենայի միջուկը ստանում է հափշտակման չափանիշը հիպերվիզորից: Միևնույն ժամանակ, հիպերվիզորը չի նշում, թե ինչ այլ գործընթացներ է նա իրականացնում, պարզապես «քանի դեռ ես զբաղված եմ, չեմ կարող ձեզ ժամանակ տալ»: KVM-ում ավելացվում է հափշտակման հաշվարկի աջակցություն կարկատաններ. Այստեղ երկու հիմնական կետ կա.

• Վիրտուալ մեքենան իմանում է գողության մասին հիպերվիզորից: Այսինքն, կորուստների տեսանկյունից, բուն վիրտուալ մեքենայի գործընթացների համար սա անուղղակի չափում է, որը կարող է ենթարկվել տարբեր աղավաղումների:
• Հիպերվիզորը չի կիսում տեղեկատվություն վիրտուալ մեքենայի հետ այն մասին, թե ինչ է անում, գլխավորն այն է, որ նա ժամանակ չի հատկացնում դրան: Դրա պատճառով վիրտուալ մեքենան ինքնին չի կարող հայտնաբերել գողության ցուցիչի աղավաղումները, որոնք կարող են գնահատվել մրցակցող գործընթացների բնույթով:

2. Ինչն է ազդում գողության վրա

2.1. Գողանալ հաշվարկ

Իրականում, գողանալը համարվում է գրեթե նույն կերպ, ինչ պրոցեսորի օգտագործման սովորական ժամանակը: Շատ տեղեկություններ չկան այն մասին, թե ինչպես է դիտարկվում վերամշակումը: Հավանաբար այն պատճառով, որ մեծամասնությունը այս հարցը ակնհայտ է համարում։ Բայց այստեղ էլ որոգայթներ կան։ Այս գործընթացի ակնարկի համար կարդացեք հոդված Բրենդան Գրեգի կողմիցՕգտագործումը հաշվարկելիս դուք կիմանաք մի շարք նրբերանգների մասին և այն իրավիճակների մասին, երբ այս հաշվարկը սխալ կլինի հետևյալ պատճառներով.

• Պրոցեսորի գերտաքացում, որի ժամանակ ցիկլերը բաց են թողնվում:
• Միացնել/անջատել turbo boost-ը, որը փոխում է պրոցեսորի ժամացույցի հաճախականությունը:
• Ժամանակային հատվածի երկարության փոփոխություն, որը տեղի է ունենում պրոցեսորի էներգախնայողության տեխնոլոգիաների օգտագործման ժամանակ, ինչպիսին է SpeedStep-ը:
• Միջին խնդրի հաշվարկ. 80% օգտագործման մեկ րոպեի գնահատումը կարող է թաքցնել 100% կարճաժամկետ պոռթկում:
• Պտտվող կողպումը առաջացնում է պրոցեսորի վերականգնում, սակայն օգտագործողի գործընթացը չի տեսնում առաջընթաց դրա կատարման մեջ: Արդյունքում պրոցեսորի գնահատված օգտագործումը գործընթացի կողմից կկազմի XNUMX%, թեև գործընթացը ֆիզիկապես պրոցեսորի ժամանակ չի խլի:

Ես չգտա հոդված, որը նկարագրում է գողության համար նմանատիպ հաշվարկ (եթե գիտեք, կիսվեք մեկնաբանություններում): Բայց, դատելով աղբյուրներից, հաշվարկման մեխանիզմը նույնն է, ինչ վերամշակման դեպքում։ Պարզապես միջուկում ավելացվում է ևս մեկ հաշվիչ՝ ուղղակիորեն KVM պրոցեսի համար (վիրտուալ մեքենայի պրոցես), որը հաշվում է KVM պրոցեսի տևողությունը պրոցեսորի ժամանակի սպասման վիճակում։ Հաշվիչը վերցնում է տեղեկատվությունը պրոցեսորի մասին իր բնութագրերից և տեսնում է, թե արդյոք դրա բոլոր տիզերը օգտագործվում են վիրտուալ մեքենայի գործընթացում: Եթե ​​ամեն ինչ, ապա մենք համարում ենք, որ պրոցեսորը զբաղված է եղել միայն վիրտուալ մեքենայի գործընթացով։ Հակառակ դեպքում հայտնում ենք, որ պրոցեսորն այլ բան էր անում, հայտնվել է գողություն։

Գողանալու հաշվման գործընթացը ենթակա է նույն խնդիրների, ինչ սովորական գողությունների հաշվարկը: Չասեմ, որ նման խնդիրներ հաճախ են հայտնվում, բայց հուսահատեցնող տեսք ունեն։

2.2. Վիրտուալացման տեսակները KVM-ում

Ընդհանուր առմամբ, վիրտուալացման երեք տեսակ կա, և բոլորն էլ աջակցվում են KVM-ի կողմից: Գողանալու մեխանիզմը կարող է կախված լինել վիրտուալացման տեսակից:

Հեռարձակում. Այս դեպքում վիրտուալ մեքենայի օպերացիոն համակարգի աշխատանքը հիպերվիզորի ֆիզիկական սարքերի հետ կատարվում է մոտավորապես այսպես.

1. Հյուրերի օպերացիոն համակարգը հրաման է ուղարկում իր հյուր սարքին:
2. Հյուր սարքի վարորդը ստանում է հրամանը, ստեղծում է հարցում սարքի BIOS-ի համար և այն ուղարկում հիպերվիզորին:
3. Hypervisor գործընթացը հրամանը թարգմանում է հրաման ֆիզիկական սարքի համար՝ այն, ի թիվս այլ բաների, դարձնելով ավելի անվտանգ:
4. Ֆիզիկական սարքի վարորդը ընդունում է փոփոխված հրամանը և ուղարկում այն ​​հենց ֆիզիկական սարքին:
5. Հրամանների կատարման արդյունքները հետ են գնում նույն ճանապարհով:

Թարգմանության առավելությունն այն է, որ այն թույլ է տալիս ընդօրինակել ցանկացած սարք և չի պահանջում օպերացիոն համակարգի միջուկի հատուկ պատրաստում։ Բայց դրա համար պետք է վճարել առաջին հերթին արագությամբ։

Սարքավորումների վիրտուալացում. Այս դեպքում սարքը ապարատային մակարդակում հասկանում է օպերացիոն համակարգի հրամանները: Սա ամենաարագ և լավագույն միջոցն է։ Բայց, ցավոք, այն չի աջակցվում բոլոր ֆիզիկական սարքերի, հիպերվիզորների և հյուրի օպերացիոն համակարգերի կողմից: Ներկայումս հիմնական սարքերը, որոնք աջակցում են ապարատային վիրտուալացմանը, պրոցեսորներն են:

Paravirtualization. KVM-ում սարքի վիրտուալացման ամենատարածված տարբերակը և ընդհանրապես հյուրի օպերացիոն համակարգերի համար ամենատարածված վիրտուալացման ռեժիմը: Դրա առանձնահատկությունն այն է, որ որոշ հիպերվիզոր ենթահամակարգերի հետ աշխատանքը (օրինակ՝ ցանցի կամ սկավառակի կույտի հետ) կամ հիշողության էջերի տեղաբաշխումը տեղի է ունենում հիպերվիզորի API-ի միջոցով՝ առանց ցածր մակարդակի հրամանների թարգմանության։ Վիրտուալիզացիայի այս մեթոդի թերությունն այն է, որ հյուր օպերացիոն համակարգի միջուկը պետք է փոփոխվի, որպեսզի այն կարողանա հաղորդակցվել հիպերվիզորի հետ՝ օգտագործելով այս API-ն: Բայց դա սովորաբար լուծվում է հյուրի օպերացիոն համակարգի վրա հատուկ դրայվերներ տեղադրելով: KVM-ում այս API-ն կոչվում է virtio API.

Պարավիրտուալիզացիայի դեպքում, համեմատած թարգմանության հետ, ֆիզիկական սարք տանող ուղին զգալիորեն կրճատվում է՝ հրամաններ ուղարկելով անմիջապես վիրտուալ մեքենայից դեպի հյուրընկալող հիպերվիզոր գործընթաց: Սա թույլ է տալիս արագացնել բոլոր հրահանգների կատարումը վիրտուալ մեքենայի ներսում: KVM-ում դրա համար պատասխանատու է virtio API-ն, որն աշխատում է միայն որոշակի սարքերի համար, օրինակ՝ ցանցի կամ սկավառակի ադապտերների համար: Այդ իսկ պատճառով virtio դրայվերները տեղադրվում են վիրտուալ մեքենաների ներսում։

Այս արագացման հակառակ կողմն այն է, որ վիրտուալ մեքենայի ներսում ոչ բոլոր գործընթացներն են մնում դրա ներսում: Սա ստեղծում է որոշ հատուկ էֆեկտներ, որոնք կարող են առաջացնել գողություն: Խորհուրդ եմ տալիս սկսել այս հարցի մանրամասն ուսումնասիրությունը API վիրտուալ I/O-ի համար՝ virtio.

2.3. «Արդար» ժամանակացույց

Հիպերվիզորի վրա վիրտուալ մեքենան, ըստ էության, կանոնավոր գործընթաց է, որը հնազանդվում է Linux-ի միջուկում ժամանակացույցի (ռեսուրսների բաշխման գործընթացների միջև) օրենքներին, ուստի եկեք ավելի մանրամասն նայենք դրան:

Linux-ն օգտագործում է այսպես կոչված CFS, Completely Fair Scheduler, որը դարձել է լռելյայն ժամանակացույցը միջուկից 2.6.23-ից ի վեր: Այս ալգորիթմը հասկանալու համար կարող եք կարդալ Linux Kernel Architecture-ը կամ աղբյուրը: CFS-ի էությունը կայանում է պրոցեսորի ժամանակի բաշխման մեջ՝ կախված դրանց կատարման տևողությունից: Որքան շատ պրոցեսորի ժամանակ է պահանջվում պրոցեսը, այնքան պրոցեսորի ժամանակն ավելի քիչ է ստանում: Սա երաշխավորում է բոլոր պրոցեսների «արդար» կատարումը, այնպես որ մի պրոցեսորը մշտապես չի զբաղեցնում բոլոր պրոցեսորները, և կարող են իրականացվել նաև այլ գործընթացներ:

Երբեմն այս պարադիգմը հանգեցնում է հետաքրքիր արտեֆակտների: Linux-ի երկարամյա օգտատերերը, անկասկած, կհիշեն սովորական տեքստային խմբագրիչի սառեցումը աշխատասեղանի վրա ռեսուրսներ պահանջող հավելվածների գործարկման ժամանակ, ինչպիսին է կոմպիլյատորը: Դա տեղի ունեցավ այն պատճառով, որ աշխատասեղանի հավելվածների ոչ ռեսուրսային առաջադրանքները մրցում էին այնպիսի առաջադրանքների հետ, որոնք ակտիվորեն սպառում են ռեսուրսները, ինչպիսին է կոմպիլյատորը: CFS-ը կարծում է, որ դա անարդար է, ուստի այն պարբերաբար դադարեցնում է տեքստային խմբագրիչը և թույլ է տալիս պրոցեսորին կարգավորել կոմպիլյատորի խնդիրները: Սա շտկվել է մեխանիզմով sched_autogroup, բայց խնդիրների միջև պրոցեսորի ժամանակի բաշխման շատ այլ առանձնահատկություններ մնացին: Իրականում, այս պատմությունը ոչ թե այն մասին է, թե որքան վատ է ամեն ինչ CFS-ում, այլ ուշադրություն հրավիրելու այն փաստի վրա, որ պրոցեսորի ժամանակի «արդար» բաշխումը ամենաչնչին խնդիրը չէ:

Ժամանակացույցի մեկ այլ կարևոր կետ նախապատվությունն է: Սա անհրաժեշտ է քմծիծաղի գործընթացը պրոցեսորից հեռացնելու և մյուսներին գործելու համար: Արտաքսման գործընթացը կոչվում է համատեքստի փոխարկում, պրոցեսորի համատեքստի փոխարկիչ: Միևնույն ժամանակ, պահպանվում է առաջադրանքի ողջ համատեքստը՝ ստեկի վիճակը, ռեգիստրները և այլն, որից հետո գործընթացն ուղարկվում է սպասելու, իսկ մյուսը փոխարինում է իր տեղը։ Սա ՕՀ-ի համար թանկ գործողություն է և հազվադեպ է օգտագործվում, բայց իրականում դրա մեջ ոչ մի վատ բան չկա: Համատեքստի հաճախակի փոխարկումը կարող է ցույց տալ ՕՀ-ի խնդիր, բայց սովորաբար այն շարունակվում է և առանձնապես ոչինչ չի նշում:

Այսքան երկար պատմություն է անհրաժեշտ մեկ փաստ բացատրելու համար. որքան շատ պրոցեսորային ռեսուրսներ փորձի պրոցեսորը սպառել ազնիվ Linux ժամանակացույցով, այնքան ավելի արագ այն կդադարեցվի, որպեսզի մյուս գործընթացները նույնպես աշխատեն: Սա ճիշտ է, թե ոչ, դժվար հարց է, որը տարբեր բեռների տակ տարբեր կերպ է լուծվում։ Windows-ում, մինչև վերջերս, ժամանակացույցը կենտրոնացած էր աշխատասեղանի հավելվածների առաջնահերթ մշակման վրա, ինչը կարող էր հանգեցնել ֆոնային գործընթացների կախման: Sun Solaris-ն ուներ հինգ տարբեր դասի ժամանակացույցեր: Երբ վիրտուալացումը գործարկվեց, ավելացվեց վեցերորդը, արդար բաժնետոմսերի ժամանակացույցքանի որ նախորդ հինգը համարժեք չեն աշխատել Solaris Zones-ի վիրտուալացման հետ: Խորհուրդ եմ տալիս այս հարցի մանրամասն ուսումնասիրությունը սկսել այնպիսի գրքերով, ինչպիսիք են Solaris Internals՝ Solaris 10 և OpenSolaris Kernel Architecture կամ Հասկանալով Linux միջուկը.

2.4. Ինչպե՞ս վերահսկել գողությունը:

Վիրտուալ մեքենայի ներսում գողության մոնիտորինգը, ինչպես ցանկացած այլ պրոցեսորի չափիչ, պարզ է. կարող եք օգտագործել ցանկացած պրոցեսորի մետրային գործիք: Հիմնական բանը այն է, որ վիրտուալ մեքենան պետք է լինի Linux-ում: Windows-ը չգիտես ինչու նման տեղեկատվություն չի տրամադրում իր օգտատերերին։ 🙁

Վերին հրամանի ելքը. մանրամասնելով պրոցեսորի բեռը, ամենաաջ սյունակում՝ գողանալ

Դժվարությունն առաջանում է, երբ փորձում են այս տեղեկատվությունը ստանալ հիպերվիզորից: Դուք կարող եք փորձել կանխատեսել գողությունը հոսթ մեքենայի վրա, օրինակ, Load Average (LA) պարամետրով - կատարման հերթում սպասող գործընթացների քանակի միջին արժեքը: Այս պարամետրը հաշվարկելու մեթոդը պարզ չէ, բայց ընդհանուր առմամբ, եթե պրոցեսորային թելերի քանակով նորմալացված LA-ն 1-ից մեծ է, դա ցույց է տալիս, որ Linux սերվերը ծանրաբեռնված է ինչ-որ բանով:

Ինչի՞ են սպասում այս բոլոր գործընթացները։ Ակնհայտ պատասխանը պրոցեսորներն են: Բայց պատասխանը լիովին ճիշտ չէ, քանի որ երբեմն պրոցեսորն անվճար է, և LA-ն դուրս է գալիս մասշտաբից: Հիշիր ինչպես է ընկնում NFS-ը և ինչպես է աճում LA-ն միաժամանակ. Մոտավորապես նույնը կարող է լինել սկավառակի և այլ մուտքային / ելքային սարքերի հետ: Բայց իրականում պրոցեսները կարող են սպասել ցանկացած կողպեքի ավարտին, թե՛ ֆիզիկական, թե՛ I/O սարքի հետ կապված, թե՛ տրամաբանական, ինչպիսին է մուտեքսը: Այն նաև ներառում է կողպեքներ ապարատային մակարդակով (նույն պատասխանը սկավառակից) կամ տրամաբանություն (այսպես կոչված, կողպման պրիմիտիվներ, որոնք ներառում են մի շարք սուբյեկտներ, mutex adaptive and spin, semaphores, condition variables, rw locks, ipc locks : ...).

LA-ի մեկ այլ առանձնահատկությունն այն է, որ այն համարվում է միջին արժեք օպերացիոն համակարգի համար: Օրինակ, 100 պրոցեսներ մրցում են մեկ ֆայլի համար, իսկ հետո LA=50: Նման մեծ արժեքը, կարծես թե, ցույց է տալիս, որ օպերացիոն համակարգը վատ է: Բայց այլ ծուռ գրված կոդի համար սա կարող է նորմալ վիճակ լինել, չնայած այն հանգամանքին, որ միայն դա է վատ, և օպերացիոն համակարգի մյուս գործընթացները չեն տուժում:

Այս միջինացման պատճառով (և ոչ պակաս, քան մեկ րոպե), LA-ի առումով որևէ բան որոշելը ամենաբարդ առաջադրանքը չէ, կոնկրետ դեպքերում շատ անորոշ արդյունքներով: Եթե ​​փորձեք պարզել դա, ապա կտեսնեք, որ Վիքիպեդիայի հոդվածները և այլ հասանելի ռեսուրսները նկարագրում են միայն ամենապարզ դեպքերը՝ առանց գործընթացի խորը բացատրության։ Բոլոր հետաքրքրվածներին ուղարկում եմ նորից, այստեղ Բրենդան Գրեգին  - հետևեք հղումներին: Ո՞վ է ծույլ անգլերենում - Լոս Անջելեսի մասին իր հայտնի հոդվածի թարգմանությունը.

3. Հատուկ էֆեկտներ

Հիմա անդրադառնանք գողության հիմնական դեպքերին, որոնց հանդիպել ենք։ Ես ձեզ կասեմ, թե ինչպես են դրանք հետևում վերը նշված բոլորից և ինչպես են դրանք փոխկապակցված հիպերվիզորի ցուցիչների հետ:

Վերամշակում. Ամենապարզն ու ամենատարածվածը՝ հիպերվիզորը վերամշակվում է: Իրոք, կան շատ աշխատող վիրտուալ մեքենաներ, դրանց ներսում պրոցեսորի մեծ սպառում, մեծ մրցակցություն, LA-ի օգտագործումը 1-ից մեծ է (նորմալացված պրոցեսորային թելերով): Բոլոր վիրտուալների ներսում ամեն ինչ դանդաղում է: Հիպերվիզորից փոխանցվող գողությունը նույնպես աճում է, անհրաժեշտ է վերաբաշխել բեռը կամ ինչ-որ մեկին անջատել։ Ընդհանրապես ամեն ինչ տրամաբանական է ու հասկանալի։

Paravirtualization ընդդեմ միայնակ դեպքերի. Հիպերվիզորի վրա կա միայն մեկ վիրտուալ մեքենա, այն սպառում է դրա մի փոքր մասը, բայց տալիս է մեծ I/O բեռ, օրինակ, սկավառակի վրա: Եվ ինչ-որ տեղից նրա մեջ հայտնվում է փոքրիկ գողություն՝ մինչև 10% (ինչպես ցույց են տալիս մի քանի փորձեր)։

Հետաքրքիր է դեպքը. Steal-ը հայտնվում է այստեղ միայն պարավիրտուալացված վարորդների մակարդակի կողպեքների պատճառով: Վիրտուալ մեքենայի ներսում ստեղծվում է ընդհատում, որը մշակվում է վարորդի կողմից և գնում դեպի հիպերվիզոր: Հիպերվիզորի վրա ընդհատումների մշակման պատճառով սա կարծես ուղարկված հարցում է վիրտուալ մեքենային, այն պատրաստ է կատարման և սպասում է պրոցեսորին, բայց պրոցեսորի ժամանակ չի տրվում: Վիրտուալ մեքենան կարծում է, որ այս ժամանակը գողացված է։

Դա տեղի է ունենում բուֆերի ուղարկման պահին, այն գնում է հիպերվիզորի միջուկի տարածք, և մենք սկսում ենք սպասել դրան։ Չնայած վիրտուալ մեքենայի տեսանկյունից նա պետք է անմիջապես վերադառնա։ Ուստի, ըստ գողության հաշվարկի ալգորիթմի, այս ժամանակը համարվում է գողացված։ Ամենայն հավանականությամբ, այս իրավիճակում կարող են լինել այլ մեխանիզմներ (օրինակ, ևս մի քանի sys զանգերի մշակում), բայց դրանք չպետք է շատ տարբերվեն։

Ժամանակացույց բարձր բեռնված վիրտուալ մեքենաների դեմ. Երբ մեկ վիրտուալ մեքենա ավելի շատ է գողանում, քան մյուսները, դա պայմանավորված է հենց ժամանակացույցով: Որքան շատ գործընթացը բեռնում է պրոցեսորը, այնքան ավելի շուտ ժամանակացույցը կհեռացնի այն, որպեսզի մնացածը նույնպես կարողանա աշխատել: Եթե ​​վիրտուալ մեքենան մի քիչ սպառում է, ապա հազիվ թե տեսնի գողություն. նրա գործընթացը ազնվորեն նստեց և սպասեց, պետք է ավելի շատ ժամանակ տալ: Եթե ​​վիրտուալ մեքենան արտադրում է առավելագույն ծանրաբեռնվածություն իր բոլոր միջուկների վրա, այն ավելի հաճախ դուրս է մղվում պրոցեսորից և փորձում են շատ ժամանակ չտալ:

Նույնիսկ ավելի վատ, երբ վիրտուալ մեքենայի ներսում գործընթացները փորձում են ավելի շատ պրոցեսոր ստանալ, քանի որ նրանք չեն կարողանում հաղթահարել տվյալների մշակումը: Այնուհետև հիպերվիզորի վրա օպերացիոն համակարգը, ազնիվ օպտիմալացման շնորհիվ, ավելի ու ավելի քիչ ժամանակ կտա պրոցեսորին։ Այս գործընթացը տեղի է ունենում ձնահյուսի նման, և գողությունը թռչում է դեպի երկինք, թեև այլ վիրտուալ մեքենաներ դժվար թե դա նկատեն: Եվ որքան շատ միջուկներ, այնքան վատ է մեքենան, որն ընկել է բաշխման տակ: Մի խոսքով, ամենաշատը տուժում են շատ միջուկներով բարձր բեռնված վիրտուալ մեքենաները:

Ցածր LA, բայց կա գողանալ. Եթե ​​LA-ն մոտ 0,7 է (այսինքն, հիպերվիզորը կարծես թե թերբեռնված է), բայց գողությունը նկատվում է առանձին վիրտուալ մեքենաների ներսում.

• Վերևում արդեն նկարագրված տարբերակը պարավիրտուալիզացիայի միջոցով: Վիրտուալ մեքենան կարող է ստանալ չափումներ, որոնք ցույց են տալիս գողությունը, թեև հիպերվիզորը լավ է աշխատում: Մեր փորձերի արդյունքների համաձայն՝ այս հափշտակման տարբերակը չի գերազանցում 10%-ը և չպետք է էական ազդեցություն ունենա վիրտուալ մեքենայի ներսում հավելվածի կատարման վրա:
• LA պարամետրը համարվում է սխալ: Ավելի ճիշտ, յուրաքանչյուր կոնկրետ պահի այն համարվում է ճիշտ, բայց երբ միջինը մեկ րոպեից ավել է, պարզվում է, որ այն թերագնահատված է։ Օրինակ, եթե հիպերվիզորի մեկ երրորդի մեկ վիրտուալ մեքենան սպառում է իր բոլոր պրոցեսորները ուղիղ կես րոպե, ապա LA-ն րոպեում հիպերվիզորի վրա կլինի 0,15; Միաժամանակ աշխատող չորս նման վիրտուալ մեքենաներ կտան 0,6: Իսկ այն, որ նրանցից յուրաքանչյուրի վրա կես րոպեի ընթացքում վայրի գողություն է տեղի ունեցել LA-ի 25%-ի չափով, այլեւս չի կարելի դուրս հանել:
• Կրկին ժամանակացույցի պատճառով, ով որոշեց, որ ինչ-որ մեկը շատ է ուտում, և թող այս մեկը սպասի: Միևնույն ժամանակ, ես կփոխեմ համատեքստը, կկարգավորեմ ընդհատումները և հոգ կտանեմ համակարգի այլ կարևոր բաների մասին: Արդյունքում, որոշ վիրտուալ մեքենաներ չեն տեսնում որևէ խնդիր, մինչդեռ մյուսները կատարում են լուրջ դեգրադացիա:

4. Այլ աղավաղումներ

Վիրտուալ մեքենայի վրա պրոցեսորի ժամանակի ազնիվ վերադարձը խեղաթյուրելու ևս միլիոն պատճառ կա: Օրինակ, hyperthreading-ը և NUMA-ն ավելացնում են հաշվարկների բարդությունը: Նրանք ամբողջովին շփոթում են միջուկի ընտրությունը գործընթացի կատարման համար, քանի որ ժամանակացույցն օգտագործում է գործակիցներ՝ կշիռներ, որոնք կոնտեքստը փոխելու ժամանակ էլ ավելի են դժվարացնում հաշվարկը։

Կան խեղաթյուրումներ, ինչպիսիք են turbo boost-ը կամ, ընդհակառակը, էներգախնայողության ռեժիմը, որը ուտիլիզացիան հաշվարկելիս կարող է արհեստականորեն ավելացնել կամ նվազեցնել հաճախականությունը կամ նույնիսկ ժամանակի քվանտը սերվերի վրա: Տուրբո խթանումը միացնելը նվազեցնում է մեկ պրոցեսորի աշխատանքը՝ մյուսի կատարողականի բարձրացման պատճառով: Այս պահին պրոցեսորի ընթացիկ հաճախականության մասին տեղեկատվությունը չի փոխանցվում վիրտուալ մեքենային, և այն կարծում է, որ ինչ-որ մեկը գողանում է իր ժամանակը (օրինակ, նա պահանջել է 2 ԳՀց, բայց ստացել է դրա կեսը)։

Ընդհանուր առմամբ, աղավաղումների պատճառները կարող են շատ լինել: Որոշակի համակարգում դուք կարող եք այլ բան գտնել: Ավելի լավ է սկսել այն գրքերից, որոնց հղումներ եմ տվել վերևում, և կարդալ վիճակագրություն հիպերվիզորից այնպիսի կոմունալ ծառայություններով, ինչպիսիք են perf, sysdig, systemtap-ը, որոնցից տասնյակ.

5: Եզրակացություններ

1. Որոշակի քանակությամբ գողություն կարող է առաջանալ պարավիրտուալիզացիայի պատճառով, և դա կարելի է նորմալ համարել: Համացանցում գրում են, որ այդ արժեքը կարող է լինել 5-10%: Դա կախված է վիրտուալ մեքենայի ներսում գտնվող հավելվածներից և այն բանից, թե ինչ ծանրաբեռնվածություն է այն տալիս իր ֆիզիկական սարքերին: Այստեղ կարևոր է ուշադրություն դարձնել, թե ինչպես են հավելվածները զգում վիրտուալ մեքենաների ներսում:
2. Վիրտուալ մեքենայի ներսում հիպերվիզորի բեռի և գողության հարաբերակցությունը միշտ չէ, որ միանշանակ փոխկապակցված է, գողության երկու գնահատականներն էլ կարող են սխալ լինել տարբեր բեռների հատուկ իրավիճակներում:
3. Ժամանակացույցը վատ է վերաբերվում գործընթացներին, որոնք շատ բան են պահանջում: Նա փորձում է ավելի քիչ տալ նրանց, ովքեր ավելին են խնդրում։ Մեծ վիրտուալ մեքենաները չարիք են:
4. Փոքր գողությունը կարող է նորմ լինել նույնիսկ առանց պարավիրտուալիզացիայի (հաշվի առնելով վիրտուալ մեքենայի ներսում բեռնվածությունը, հարևանների բեռնվածքի բնութագրերը, բեռների բաշխումը թելերի միջև և այլ գործոններ):
5. Եթե ​​ցանկանում եք պարզել գողությունը որոշակի համակարգում, դուք պետք է ուսումնասիրեք տարբեր տարբերակներ, հավաքեք չափումներ, ուշադիր վերլուծեք դրանք և մտածեք, թե ինչպես հավասարաչափ բաշխել բեռը: Հնարավոր են շեղումներ ցանկացած դեպքից, որը պետք է հաստատվի փորձարարական կամ փնտրվի միջուկի վրիպազերծիչում:

Source: www.habr.com