ვირტუალური მანქანის მუშაობის ანალიზი VMware vSphere-ში. ნაწილი 1: CPU

თუ თქვენ მართავთ ვირტუალურ ინფრასტრუქტურას, რომელიც დაფუძნებულია VMware vSphere-ზე (ან ნებისმიერი სხვა ტექნოლოგიის დასტაზე), ალბათ ხშირად გესმით მომხმარებლების პრეტენზია: „ვირტუალური მანქანა ნელია!“ სტატიების ამ სერიაში გავაანალიზებ შესრულების მეტრიკას და გეტყვით, რა და რატომ ანელებს ის და როგორ დავრწმუნდეთ, რომ არ შენელდება.

მე განვიხილავ ვირტუალური მანქანის მუშაობის შემდეგ ასპექტებს:

• ᲞᲠᲝᲪᲔᲡᲝᲠᲘ,
• RAM,
• დისკი,
• ქსელი.

დავიწყებ პროცესორით.

შესრულების გასაანალიზებლად დაგვჭირდება:

• vCenter შესრულების მრიცხველები – შესრულების მრიცხველები, რომელთა გრაფიკების ნახვა შესაძლებელია vSphere Client-ის მეშვეობით. ინფორმაცია ამ მრიცხველებზე ხელმისაწვდომია კლიენტის ნებისმიერ ვერსიაში ("სქელი" კლიენტი C#-ში, ვებ კლიენტი Flex-ში და ვებ კლიენტი HTML5-ში). ამ სტატიებში ჩვენ გამოვიყენებთ ეკრანის სურათებს C# კლიენტისგან, მხოლოდ იმიტომ, რომ ისინი უკეთესად გამოიყურებიან მინიატურაში :)
• ESXTOP – პროგრამა, რომელიც მუშაობს ESXi ბრძანების ხაზიდან. მისი დახმარებით შეგიძლიათ მიიღოთ შესრულების მრიცხველების მნიშვნელობები რეალურ დროში ან ატვირთოთ ეს მნიშვნელობები გარკვეული პერიოდის განმავლობაში .csv ფაილში შემდგომი ანალიზისთვის. შემდეგი, მე გეტყვით დაწვრილებით ამ ხელსაწყოს შესახებ და მოგაწოდებთ რამდენიმე სასარგებლო ბმულს ამ თემაზე დოკუმენტაციისა და სტატიების შესახებ.

ცოტა თეორია

ESXi-ში ცალკე პროცესი - სამყარო VMware ტერმინოლოგიაში - პასუხისმგებელია თითოეული vCPU-ს (ვირტუალური მანქანის ბირთვი) მუშაობაზე. ასევე არსებობს სერვისის პროცესები, მაგრამ VM მუშაობის ანალიზის თვალსაზრისით ისინი ნაკლებად საინტერესოა.

პროცესი ESXi-ში შეიძლება იყოს ოთხი მდგომარეობიდან ერთ-ერთში:

• გასაშვებად - პროცესი ასრულებს გარკვეულ სასარგებლო სამუშაოს.
• დაელოდეთ – პროცესი არ აკეთებს რაიმე სამუშაოს (უმოქმედო) ან ელოდება შეყვანას/გამომავალს.
• კოსტოპ - მდგომარეობა, რომელიც გვხვდება მრავალ ბირთვიან ვირტუალურ მანქანებში. ეს ხდება მაშინ, როდესაც ჰიპერვიზორის CPU განრიგს (ESXi CPU Scheduler) არ შეუძლია დაგეგმოს ყველა აქტიური ვირტუალური აპარატის ბირთვების ერთდროული შესრულება სერვერის ფიზიკურ ბირთვებზე. ფიზიკურ სამყაროში, ყველა პროცესორის ბირთვი მუშაობს პარალელურად, სტუმარი OS შიგნით VM მოელის მსგავს ქცევას, ამიტომ ჰიპერვიზორმა უნდა შეანელოს VM ბირთვები, რომლებსაც აქვთ უნარი დაასრულონ საათის ციკლი უფრო სწრაფად. ESXi-ის თანამედროვე ვერსიებში, პროცესორის განრიგი იყენებს მექანიზმს, რომელსაც ეწოდება მოდუნებული თანადაგეგმვა: ჰიპერვიზორი განიხილავს უფსკრული „ყველაზე სწრაფ“ და „ყველაზე ნელ“ ვირტუალური მანქანის ბირთვს (დახრილობას) შორის. თუ უფსკრული გადააჭარბებს გარკვეულ ზღურბლს, სწრაფი ბირთვი შედის კოსტოპ მდგომარეობაში. თუ VM ბირთვები დიდ დროს ატარებენ ამ მდგომარეობაში, ამან შეიძლება გამოიწვიოს მუშაობის პრობლემები.
• Ready – პროცესი შედის ამ მდგომარეობაში, როდესაც ჰიპერვიზორს არ შეუძლია რესურსების გამოყოფა მისი შესრულებისთვის. მაღალ მზა მნიშვნელობებმა შეიძლება გამოიწვიოს VM მუშაობის პრობლემები.

ძირითადი ვირტუალური აპარატის CPU მუშაობის მრიცხველები

Პროცესორის გამოყენება, %. აჩვენებს CPU-ს გამოყენების პროცენტს მოცემულ პერიოდში.

როგორ გავაანალიზოთ? თუ VM მუდმივად იყენებს CPU-ს 90%-ზე ან არის პიკი 100%-მდე, მაშინ გვაქვს პრობლემები. პრობლემები შეიძლება გამოიხატოს არა მხოლოდ VM-ის შიგნით აპლიკაციის „ნელი“ ფუნქციონირებით, არამედ ქსელის საშუალებით VM-ის მიუწვდომელობით. თუ მონიტორინგის სისტემა აჩვენებს, რომ VM პერიოდულად ეცემა, ყურადღება მიაქციეთ CPU Usage გრაფიკის პიკებს.

არსებობს სტანდარტული სიგნალიზაცია, რომელიც აჩვენებს ვირტუალური მანქანის CPU დატვირთვას:

რა უნდა გავაკეთოთ? თუ VM-ის CPU გამოყენება მუდმივად გადის სახურავზე, მაშინ შეგიძლიათ იფიქროთ vCPU-ების რაოდენობის გაზრდაზე (სამწუხაროდ, ეს ყოველთვის არ გეხმარებათ) ან VM-ის გადატანა სერვერზე უფრო ძლიერი პროცესორებით.

CPU გამოყენება MHz-ში

vCenter Usage-ის გრაფიკებში %-ში შეგიძლიათ იხილოთ მხოლოდ მთელი ვირტუალური მანქანა; არ არის გრაფიკები ცალკეული ბირთვებისთვის (Esxtop-ში არის % მნიშვნელობები ბირთვებისთვის). თითოეული ბირთვისთვის შეგიძლიათ იხილოთ გამოყენება MHz-ში.

როგორ გავაანალიზოთ? ეს ხდება, რომ აპლიკაცია არ არის ოპტიმიზირებული მრავალბირთვიანი არქიტექტურისთვის: ის იყენებს მხოლოდ ერთ ბირთვს 100%, ხოლო დანარჩენი უმოქმედოა დატვირთვის გარეშე. მაგალითად, ნაგულისხმევი სარეზერვო პარამეტრებით, MS SQL იწყებს პროცესს მხოლოდ ერთ ბირთვზე. შედეგად, სარეზერვო ასლი ნელდება არა დისკების ნელი სიჩქარის გამო (ეს არის ის, რასაც თავდაპირველად უჩიოდა მომხმარებელი), არამედ იმიტომ, რომ პროცესორი ვერ უმკლავდება. პრობლემა მოგვარდა პარამეტრების შეცვლით: სარეზერვო ასლი დაიწყო პარალელურად რამდენიმე ფაილში (შესაბამისად, რამდენიმე პროცესში).

ბირთვებზე არათანაბარი დატვირთვის მაგალითი.

ასევე არის სიტუაცია (როგორც ზემოთ მოცემულ გრაფიკში), როდესაც ბირთვები არათანაბრად დატვირთულია და ზოგიერთ მათგანს აქვს 100% მწვერვალი. როგორც მხოლოდ ერთი ბირთვის ჩატვირთვისას, CPU გამოყენების სიგნალიზაცია არ იმუშავებს (ეს არის მთელი VM-ისთვის), მაგრამ იქნება მუშაობის პრობლემები.

რა უნდა გავაკეთოთ? თუ პროგრამული უზრუნველყოფა ვირტუალურ მანქანაში იტვირთება ბირთვები არათანაბრად (იყენებს მხოლოდ ერთ ბირთვს ან ბირთვების ნაწილს), აზრი არ აქვს მათი რაოდენობის გაზრდას. ამ შემთხვევაში სჯობს VM გადაიტანოთ უფრო მძლავრი პროცესორების მქონე სერვერზე.

ასევე შეგიძლიათ სცადოთ ენერგიის მოხმარების პარამეტრების შემოწმება სერვერის BIOS-ში. ბევრი ადმინისტრატორი ჩართავს მაღალი ხარისხის რეჟიმს BIOS-ში და ამით გამორთავს C- და P-სახელმწიფოების ენერგიის დაზოგვის ტექნოლოგიებს. Intel-ის თანამედროვე პროცესორები იყენებენ Turbo Boost ტექნოლოგიას, რომელიც ზრდის ცალკეული პროცესორის ბირთვების სიხშირეს სხვა ბირთვების ხარჯზე. მაგრამ ის მუშაობს მხოლოდ მაშინ, როდესაც ჩართულია ენერგიის დაზოგვის ტექნოლოგიები. თუ მათ გამორთავთ, პროცესორი ვერ შეამცირებს ენერგიის მოხმარებას იმ ბირთვების, რომლებიც არ არის დატვირთული.

VMware გირჩევთ არ გამორთოთ ენერგიის დაზოგვის ტექნოლოგიები სერვერებზე, არამედ აირჩიოთ ისეთი რეჟიმები, რომლებიც ელექტროენერგიის მართვას მაქსიმალურად უტოვებს ჰიპერვიზორს. ამ შემთხვევაში, ჰიპერვიზორის ენერგიის მოხმარების პარამეტრებში, თქვენ უნდა აირჩიოთ მაღალი შესრულება.

თუ თქვენ გაქვთ ინდივიდუალური VM-ები (ან VM ბირთვები) თქვენს ინფრასტრუქტურაში, რომლებიც საჭიროებენ CPU-ს გაზრდის სიხშირეს, ენერგიის მოხმარების სწორად კორექტირებამ შეიძლება მნიშვნელოვნად გააუმჯობესოს მათი შესრულება.

CPU მზადაა

თუ VM ბირთვი (vCPU) მზადაა, ის არ ასრულებს სასარგებლო სამუშაოს. ეს მდგომარეობა ჩნდება მაშინ, როდესაც ჰიპერვიზორი ვერ პოულობს თავისუფალ ფიზიკურ ბირთვს, რომელსაც შეიძლება მიენიჭოს ვირტუალური მანქანის vCPU პროცესი.

როგორ გავაანალიზოთ? როგორც წესი, თუ ვირტუალური მანქანის ბირთვები მზა მდგომარეობაშია 10%-ზე მეტ დროს, შეამჩნევთ მუშაობის პრობლემებს. მარტივად რომ ვთქვათ, 10%-ზე მეტი დროის VM ელოდება ფიზიკური რესურსების ხელმისაწვდომობას.

vCenter-ში შეგიძლიათ ნახოთ CPU Ready-თან დაკავშირებული 2 მრიცხველი:

• მზადყოფნა,
• მზად არის.

ორივე მრიცხველის მნიშვნელობების ნახვა შესაძლებელია როგორც მთელი VM-სთვის, ასევე ცალკეული ბირთვებისთვის.
მზადყოფნა აჩვენებს მნიშვნელობას დაუყოვნებლივ პროცენტულად, მაგრამ მხოლოდ რეალურ დროში (მონაცემები ბოლო საათის განმავლობაში, გაზომვის ინტერვალი 20 წამი). უმჯობესია გამოიყენოთ ეს მრიცხველი მხოლოდ „ქუსლებზე ცხელი“ პრობლემების მოსაძებნად.

მზა მრიცხველის მნიშვნელობები ასევე შეიძლება განიხილებოდეს ისტორიული პერსპექტივიდან. ეს სასარგებლოა შაბლონების დასადგენად და პრობლემის ღრმა ანალიზისთვის. მაგალითად, თუ ვირტუალური მანქანა გარკვეულ დროს იწყებს მუშაობის პრობლემების წინაშე, შეგიძლიათ შეადაროთ CPU Ready მნიშვნელობის ინტერვალები მთლიან დატვირთვას სერვერზე, სადაც მუშაობს ეს VM, და მიიღოთ ზომები დატვირთვის შესამცირებლად (თუ DRS მარცხდება).

Ready, განსხვავებით მზადყოფნისგან, ნაჩვენებია არა პროცენტებში, არამედ მილიწამებში. ეს არის Sumation ტიპის მრიცხველი, ანუ ის აჩვენებს რამდენ ხანს იყო გაზომვის პერიოდში VM ბირთვი მზად მდგომარეობაში. თქვენ შეგიძლიათ გადაიყვანოთ ეს მნიშვნელობა პროცენტულად მარტივი ფორმულის გამოყენებით:

(CPU მზად შემაჯამებელი მნიშვნელობა / (დიაგრამის განახლების ნაგულისხმევი ინტერვალი წამებში * 1000)) * 100 = CPU მზად %

მაგალითად, VM-სთვის ქვემოთ მოცემულ გრაფიკზე, პიკური Ready მნიშვნელობა მთელი ვირტუალური მანქანისთვის იქნება შემდეგი:

მზა პროცენტის გაანგარიშებისას ყურადღება უნდა მიაქციოთ ორ პუნქტს:

• Ready მნიშვნელობა მთელი VM-ისთვის არის Ready-ის ჯამი ბირთვებს შორის.
• გაზომვის ინტერვალი. რეალურ დროში ეს არის 20 წამი, ხოლო, მაგალითად, ყოველდღიურ ჩარტებზე ეს არის 300 წამი.

პრობლემების აქტიური მოგვარებით, ეს მარტივი პუნქტები ადვილად შეიძლება გამოტოვოთ და ძვირფასი დრო დაიხარჯოთ არარსებული პრობლემების გადაჭრაზე.

მოდით გამოვთვალოთ Ready ქვემოთ მოცემული გრაფიკის მონაცემებზე დაყრდნობით. (324474/(20*1000))*100 = 1622% მთელი VM-ისთვის. ბირთვებს თუ დააკვირდებით, არც ისე საშინელია: 1622 წელი/64 = 25% თითო ბირთვზე. ამ შემთხვევაში, დაჭერა საკმაოდ ადვილი შესამჩნევია: Ready მნიშვნელობა არარეალურია. მაგრამ თუ ვსაუბრობთ 10-20% -ზე მთელი VM-სთვის რამდენიმე ბირთვით, მაშინ თითოეული ბირთვისთვის მნიშვნელობა შეიძლება იყოს ნორმალურ დიაპაზონში.

რა უნდა გავაკეთოთ? მაღალი Ready მნიშვნელობა მიუთითებს, რომ სერვერს არ აქვს საკმარისი პროცესორის რესურსი ვირტუალური მანქანების ნორმალური მუშაობისთვის. ასეთ სიტუაციაში რჩება მხოლოდ პროცესორის (vCPU:pCPU) ზედმეტად გამოწერის შემცირება. ცხადია, ამის მიღწევა შესაძლებელია არსებული VM-ების პარამეტრების შემცირებით ან VM-ების ნაწილის სხვა სერვერებზე მიგრაციით.

Co-stop

როგორ გავაანალიზოთ? ეს მრიცხველი ასევე არის Sumation ტიპის და გარდაიქმნება პროცენტებში ისევე, როგორც Ready:

(CPU co-stop შეჯამების მნიშვნელობა / (დიაგრამის ნაგულისხმევი განახლების ინტერვალი წამებში * 1000)) * 100 = CPU co-stop %

აქ ასევე უნდა მიაქციოთ ყურადღება VM-ზე ბირთვების რაოდენობას და გაზომვის ინტერვალს.
კოსტოპის მდგომარეობაში ბირთვი არ ასრულებს სასარგებლო სამუშაოს. VM ზომის სწორი შერჩევით და სერვერზე ნორმალური დატვირთვით, co-stop მრიცხველი უნდა იყოს ნულთან ახლოს.

ამ შემთხვევაში დატვირთვა აშკარად არანორმალურია :)

რა უნდა გავაკეთოთ? თუ რამდენიმე VM დიდი რაოდენობის ბირთვით მუშაობს ერთ ჰიპერვიზორზე და არის გადაჭარბებული გამოწერა CPU-ზე, მაშინ Co-stop მრიცხველი შეიძლება გაიზარდოს, რაც გამოიწვევს ამ VM-ების მუშაობას პრობლემებს.

ასევე, co-stop გაიზრდება, თუ ერთი VM-ის აქტიური ბირთვები გამოიყენებენ thread-ებს ერთ ფიზიკურ სერვერის ბირთვზე, ჰიპერ-ტრედინგი ჩართულია. ეს სიტუაცია შეიძლება წარმოიშვას, მაგალითად, თუ VM-ს აქვს მეტი ბირთვი, ვიდრე ფიზიკურად ხელმისაწვდომია სერვერზე, სადაც ის მუშაობს, ან თუ "preferHT" პარამეტრი ჩართულია VM-ისთვის. შეგიძლიათ წაიკითხოთ ამ პარამეტრის შესახებ აქ.

იმისათვის, რომ თავიდან იქნას აცილებული პრობლემები VM-ის მუშაობასთან დაკავშირებული მაღალი კოსტოპის გამო, აირჩიეთ VM ზომა პროგრამული უზრუნველყოფის მწარმოებლის რეკომენდაციების შესაბამისად, რომელიც მუშაობს ამ VM-ზე და იმ ფიზიკური სერვერის შესაძლებლობების შესაბამისად, სადაც მუშაობს VM.

ნუ დაამატებთ ბირთვებს რეზერვში; ამან შეიძლება გამოიწვიოს მუშაობის პრობლემები არა მხოლოდ თავად VM-ისთვის, არამედ სერვერის მეზობლებისთვისაც.

სხვა სასარგებლო CPU მეტრიკა

გასაშვებად – რამდენი დრო (მმ) იყო გაზომვის პერიოდში vCPU RUN-ის მდგომარეობაში, ანუ რეალურად ასრულებდა სასარგებლო სამუშაოს.

Idle – რამდენ ხანს (ms) იყო გაზომვის პერიოდში vCPU უმოქმედო მდგომარეობაში. მაღალი უმოქმედო მნიშვნელობები პრობლემას არ წარმოადგენს, vCPU-ს უბრალოდ „გასაკეთებელი არაფერი ჰქონდა“.

დაელოდეთ – რამდენ ხანს (ms) იყო გაზომვის პერიოდში vCPU მოლოდინის მდგომარეობაში. ვინაიდან IDLE შედის ამ მრიცხველში, მაღალი ლოდინის მნიშვნელობები ასევე არ მიუთითებს პრობლემაზე. მაგრამ თუ Wait IDLE დაბალია, როდესაც Wait მაღალია, ეს ნიშნავს, რომ VM ელოდა I/O ოპერაციების დასრულებას და ეს, თავის მხრივ, შეიძლება მიუთითებდეს პრობლემაზე მყარი დისკის ან VM-ის ნებისმიერი ვირტუალური მოწყობილობის მუშაობაზე.

მაქსიმალური შეზღუდულია – რამდენ ხანს (ms) იყო გაზომვის პერიოდში vCPU მზა მდგომარეობაში რესურსის დაყენებული ლიმიტის გამო. თუ შესრულება აუხსნელად დაბალია, მაშინ სასარგებლოა შეამოწმოთ ამ მრიცხველის მნიშვნელობა და CPU ლიმიტი VM პარამეტრებში. VM-ებს შეიძლება მართლაც ჰქონდეს შეზღუდვები, რომელთა შესახებაც თქვენ არ იცით. მაგალითად, ეს ხდება მაშინ, როდესაც VM კლონირებული იქნა შაბლონიდან, რომელზეც დაყენებული იყო CPU ლიმიტი.

გაცვალეთ დაელოდეთ – რამდენ ხანს ელოდა vCPU ოპერაციას VMkernel Swap-ით გაზომვის პერიოდში. თუ ამ მრიცხველის მნიშვნელობები ნულზე მეტია, მაშინ VM-ს ნამდვილად აქვს მუშაობის პრობლემები. SWAP-ზე მეტს ვისაუბრებთ სტატიაში RAM მრიცხველების შესახებ.

ESXTOP

თუ vCenter-ში შესრულების მრიცხველები კარგია ისტორიული მონაცემების გასაანალიზებლად, მაშინ პრობლემის ოპერატიული ანალიზი უკეთესია ESXTOP-ში. აქ ყველა მნიშვნელობა წარმოდგენილია მზა ფორმით (არაფრის თარგმნა არ არის საჭირო), ხოლო გაზომვის მინიმალური პერიოდია 2 წამი.
ESXTOP ეკრანი CPU-სთვის გამოიძახება "c" ღილაკით და ასე გამოიყურება:

მოხერხებულობისთვის, შეგიძლიათ დატოვოთ მხოლოდ ვირტუალური მანქანების პროცესები Shift-V დაჭერით.
ცალკეული VM ბირთვების მეტრიკის სანახავად დააჭირეთ „e“-ს და შეიყვანეთ საინტერესო VM-ის GID (30919 ქვემოთ მოცემულ ეკრანის სურათზე):

ნება მომეცით მოკლედ გადავიტანო ნაგულისხმევად წარმოდგენილი სვეტები. დამატებითი სვეტების დამატება შესაძლებელია "f" დაჭერით.

NWLD (სამყაროების რაოდენობა) – პროცესების რაოდენობა ჯგუფში. ჯგუფის გასაფართოებლად და თითოეული პროცესის მეტრიკის სანახავად (მაგალითად, მრავალბირთვიანი VM-ის თითოეული ბირთვისთვის), დააჭირეთ „e“. თუ ჯგუფში არის ერთზე მეტი პროცესი, მაშინ ჯგუფისთვის მეტრიკული მნიშვნელობები უდრის ცალკეული პროცესების მეტრიკის ჯამს.

%ᲒᲐᲛᲝᲧᲔᲜᲔᲑᲣᲚᲘ – რამდენი სერვერის CPU ციკლი გამოიყენება პროცესის ან პროცესების ჯგუფის მიერ.

%RUN – რამდენ ხანს იყო პროცესი გაზომვის პერიოდში RUN მდგომარეობაში, ე.ი. სასარგებლო სამუშაო გააკეთა. ის განსხვავდება %USED-ისგან იმით, რომ არ ითვალისწინებს ჰიპერთრედირებას, სიხშირის სკალირებას და სისტემის ამოცანებზე დახარჯულ დროს (%SYS).

%SYS – სისტემურ ამოცანებზე დახარჯული დრო, მაგალითად: შეფერხების დამუშავება, I/O, ქსელის მუშაობა და ა.შ. მნიშვნელობა შეიძლება იყოს მაღალი, თუ VM-ს აქვს დიდი I/O.

%OVRLP - რამდენი დრო დახარჯა ფიზიკური ბირთვი, რომელზედაც მუშაობს VM პროცესი, სხვა პროცესების ამოცანებს.

ეს მეტრიკები ერთმანეთთან დაკავშირებულია შემდეგნაირად:

%USED = %RUN + %SYS - %OVRLP.

როგორც წესი, %USED მეტრიკა უფრო ინფორმატიულია.

დაელოდეთ – რამდენ ხანს იყო პროცესი გაზომვის პერიოდში მოლოდინის მდგომარეობაში. რთავს IDLE-ს.

%IDLE – რამდენ ხანს იყო პროცესი გაზომვის პერიოდში 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-ს ასევე აქვს CPU-ის მუშაობის მრიცხველები ჰიპერვიზორისთვის, მაგრამ ისინი არაფერია საინტერესო - ისინი უბრალოდ სერვერზე ყველა VM-ის მრიცხველების ჯამია.
სერვერზე CPU-ის სტატუსის სანახავად ყველაზე მოსახერხებელი გზა არის შეჯამების ჩანართზე:

სერვერისთვის, ისევე როგორც ვირტუალური მანქანისთვის, არის სტანდარტული სიგნალიზაცია:

როდესაც სერვერის CPU დატვირთვა მაღალია, მასზე მომუშავე ვირტუალური მანქანები იწყებენ მუშაობის პრობლემებს.

ESXTOP-ში სერვერის CPU დატვირთვის მონაცემები წარმოდგენილია ეკრანის ზედა ნაწილში. გარდა სტანდარტული CPU დატვირთვისა, რომელიც არ არის ძალიან ინფორმატიული ჰიპერვიზორებისთვის, არსებობს კიდევ სამი მეტრიკა:

CORE UTIL (%) – ფიზიკური სერვერის ბირთვის ჩატვირთვა. ეს მრიცხველი გვიჩვენებს, რამდენ დროს ასრულებდა ბირთვი სამუშაოს გაზომვის პერიოდში.

PCPU UTIL(%) – თუ ჰიპერ-თრედინგი ჩართულია, მაშინ ფიზიკურ ბირთვზე არის ორი ძაფი (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-ს ასევე აქვს ეკრანი სერვერის CPU ენერგიის მოხმარების პარამეტრებით. აქ შეგიძლიათ ნახოთ, იყენებს თუ არა სერვერი ენერგიის დაზოგვის ტექნოლოგიებს: C-სახელმწიფოები და P-სახელმწიფოები. გამოძახებული "p" კლავიშით:

CPU–ს მუშაობის საერთო პრობლემები

და ბოლოს, მე გადავხედავ VM CPU-ს მუშაობასთან დაკავშირებული პრობლემების ტიპურ მიზეზებს და მივცემ მოკლე რჩევებს მათ გადასაჭრელად:

ძირითადი საათის სიჩქარე არ არის საკმარისი. თუ შეუძლებელია თქვენი VM-ის უფრო მძლავრ ბირთვებზე განახლება, შეგიძლიათ სცადოთ კვების პარამეტრების შეცვლა, რათა Turbo Boost უფრო ეფექტურად იმუშაოს.

არასწორი VM ზომა (ძალიან ბევრი / ცოტა ბირთვი). თუ რამდენიმე ბირთვს დააინსტალირებთ, VM-ზე იქნება მაღალი CPU დატვირთვა. თუ ბევრია, დაიჭირეთ მაღალი კო-სტოპი.

CPU-ის დიდი გადაჭარბება სერვერზე. თუ VM-ს აქვს მაღალი Ready, შეამცირეთ CPU-ს გადაჭარბებული გამოწერა.

არასწორი NUMA ტოპოლოგია დიდ VM-ებზე. VM-ის მიერ დანახული NUMA ტოპოლოგია (vNUMA) უნდა ემთხვეოდეს სერვერის NUMA ტოპოლოგიას (pNUMA). დიაგნოსტიკა და ამ პრობლემის შესაძლო გადაწყვეტილებები დაწერილია, მაგალითად, წიგნში "VMware vSphere 6.5 Host Resources Deep Dive". თუ არ გსურთ ღრმად ჩასვლა და არ გაქვთ ლიცენზირების შეზღუდვები VM-ზე დაინსტალირებული OS-ზე, გააკეთეთ მრავალი ვირტუალური სოკეტი VM-ზე, თითო ბირთვით. ბევრს არ დაკარგავ :)

ეს ყველაფერი ჩემთვის CPU-ზეა. დასვით კითხვები. შემდეგ ნაწილში მე ვისაუბრებ RAM-ზე.

სასარგებლო ბმულებიhttp://virtual-red-dot.info/vm-cpu-counters-vsphere/
https://kb.vmware.com/kb/1017926
http://www.yellow-bricks.com/2012/07/17/why-is-wait-so-high/
https://communities.vmware.com/docs/DOC-9279
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/whats-new-vsphere65-perf.pdf
https://pages.rubrik.com/host-resources-deep-dive_request.html

წყარო: www.habr.com