Steal: ვინ იპარავს პროცესორის დროს ვირტუალური მანქანებიდან

გამარჯობა! მე მინდა გითხრათ მარტივი სიტყვებით ვირტუალურ აპარატებში ქურდობის მექანიკის შესახებ და რამდენიმე არააშკარა არტეფაქტის შესახებ, რომელიც ჩვენ მოვახერხეთ მისი კვლევის დროს გაგვერკვია, რაც მომიწია, როგორც ღრუბლოვანი პლატფორმის ტექნიკური დირექტორი. Mail.ru Cloud Solutions. პლატფორმა მუშაობს KVM-ზე.

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

1. რა არის ქურდობა

ამრიგად, ქურდობა არის მეტრიკა, რომელიც მიუთითებს პროცესორის დროის ნაკლებობაზე ვირტუალურ მანქანაში მიმდინარე პროცესებისთვის. Როგორც აღწერილია KVM ბირთვის პატჩშიStealth არის დრო, რომლის დროსაც ჰიპერვიზორი ახორციელებს სხვა პროცესებს მასპინძელ OS-ზე, მიუხედავად იმისა, რომ მან რიგში დააყენა ვირტუალური მანქანის პროცესი შესასრულებლად. ანუ, ქურდობა გამოითვლება, როგორც განსხვავება დროს, როდესაც პროცესი მზად არის შესასრულებლად და დროს, როდესაც პროცესს ენიჭება პროცესორის დრო.

ვირტუალური მანქანის ბირთვი იღებს მოპარვის მეტრიკას ჰიპერვიზორისგან. ამავდროულად, ჰიპერვიზორი არ აკონკრეტებს ზუსტად რა სხვა პროცესებს ატარებს, ის უბრალოდ ამბობს: „სანამ დაკავებული ვარ, დროს ვერ მოგცემ“. KVM-ზე დაემატა მოპარვის გაანგარიშების მხარდაჭერა პატჩები. აქ ორი ძირითადი პუნქტია:

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

2. რა გავლენას ახდენს ქურდობაზე

2.1. მოპარვის გაანგარიშება

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

• პროცესორი გადახურდება, რაც იწვევს ციკლების გამოტოვებას.
• ჩართეთ/გამორთეთ ტურბო გამაძლიერებელი, რომელიც ცვლის პროცესორის საათის სიხშირეს.
• დროის მონაკვეთის ხანგრძლივობის ცვლილება, რომელიც ხდება პროცესორის ენერგიის დაზოგვის ტექნოლოგიების გამოყენებისას, როგორიცაა SpeedStep.
• საშუალოს გამოთვლის პრობლემა: ერთი წუთის გამოყენების 80%-ზე შეფასებამ შეიძლება დამალოს 100%-იანი მოკლევადიანი აფეთქება.
• spin lock იწვევს პროცესორის აღდგენას, მაგრამ მომხმარებლის პროცესი ვერ ხედავს რაიმე პროგრესს მის შესრულებაში. შედეგად, პროცესის მიერ გამოთვლილი პროცესორის გამოყენება იქნება ასი პროცენტი, თუმცა პროცესი ფიზიკურად არ მოიხმარს პროცესორის დროს.

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

ქურდობის დათვლის პროცესი ექვემდებარება იგივე პრობლემებს, როგორც რეგულარული გადამუშავების დათვლა. არ ვთქვა, რომ ასეთი პრობლემები ხშირად ჩნდება, მაგრამ ისინი გულდასაწყვეტად გამოიყურება.

2.2. ვირტუალიზაციის სახეები KVM-ზე

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

მაუწყებლობა. ამ შემთხვევაში, ვირტუალური მანქანის ოპერაციული სისტემის მუშაობა ფიზიკური ჰიპერვიზორის მოწყობილობებით ხდება დაახლოებით ასე:

1. სტუმარი ოპერაციული სისტემა აგზავნის ბრძანებას სტუმრის მოწყობილობაზე.
2. სტუმარი მოწყობილობის დრაივერი იღებს ბრძანებას, ქმნის მოთხოვნას მოწყობილობის BIOS-ზე და აგზავნის მას ჰიპერვიზორს.
3. ჰიპერვიზორის პროცესი თარგმნის ბრძანებას ბრძანებად ფიზიკური მოწყობილობისთვის, რაც მას, სხვა საკითხებთან ერთად, უფრო უსაფრთხოს ხდის.
4. ფიზიკური მოწყობილობის დრაივერი იღებს შეცვლილ ბრძანებას და აგზავნის მას თავად ფიზიკურ მოწყობილობაზე.
5. ბრძანებების შესრულების შედეგები იმავე გზაზე ბრუნდება.

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

აპარატურის ვირტუალიზაცია. ამ შემთხვევაში, მოწყობილობა ტექნიკის დონეზე ესმის ოპერაციული სისტემის ბრძანებებს. ეს არის ყველაზე სწრაფი და საუკეთესო გზა. მაგრამ, სამწუხაროდ, ის არ არის მხარდაჭერილი ყველა ფიზიკური მოწყობილობის, ჰიპერვიზორის და სტუმრის ოპერაციული სისტემის მიერ. ამჟამად, ძირითადი მოწყობილობები, რომლებიც მხარს უჭერენ ტექნიკის ვირტუალიზაციას, არის პროცესორები.

პარავირტუალიზაცია. მოწყობილობის ვირტუალიზაციის ყველაზე გავრცელებული ვარიანტი 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-ში, არამედ მცდელობა გავამახვილო ყურადღება იმაზე, რომ პროცესორის დროის „სამართლიანი“ განაწილება არ არის ყველაზე ტრივიალური ამოცანა.

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

ასეთი გრძელი ამბავია საჭირო ერთი ფაქტის ასახსნელად: რაც უფრო მეტი პროცესორის რესურსი შეეცდება მოიხმაროს პროცესმა პატიოსანი ლინუქსის დაგეგმარში, მით უფრო სწრაფად შეჩერდება, რათა სხვა პროცესებმაც იმუშაონ. სწორია თუ არა ეს რთული საკითხია, რომელიც შეიძლება სხვადასხვაგვარად გადაწყდეს სხვადასხვა დატვირთვის ქვეშ. Windows-ში, ბოლო დრომდე, გრაფიკი ორიენტირებული იყო დესკტოპის აპლიკაციების პრიორიტეტულ დამუშავებაზე, რამაც შეიძლება გამოიწვიოს ფონური პროცესების გაყინვა. Sun Solaris-ს ჰყავდა განრიგის ხუთი განსხვავებული კლასი. როდესაც ვირტუალიზაცია დავიწყეთ, დავამატეთ მეექვსე, სამართლიანი გაზიარების გრაფიკი, რადგან წინა ხუთმა არ იმუშავა ადეკვატურად Solaris Zones-ის ვირტუალიზაციასთან. გირჩევთ დაიწყოთ ამ საკითხის დეტალური შესწავლა ისეთი წიგნებით, როგორიცაა Solaris Internals: Solaris 10 და OpenSolaris Kernel Architecture ან Linux Kernel-ის გაგება.

2.4. როგორ დავაკვირდეთ ქურდობას?

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

ზედა ბრძანების გამომავალი: პროცესორის დატვირთვის დეტალები, ყველაზე მარჯვენა სვეტში - steal

სირთულე წარმოიქმნება ჰიპერვიზორისგან ამ ინფორმაციის მოპოვების მცდელობისას. შეგიძლიათ სცადოთ მოპარვის პროგნოზირება მასპინძელ მანქანაზე, მაგალითად, Load Average (LA) პარამეტრის გამოყენებით - შესრულების რიგში მომლოდინე პროცესების რაოდენობის საშუალო მნიშვნელობა. ამ პარამეტრის გამოთვლის მეთოდი მარტივი არ არის, მაგრამ ზოგადად, თუ LA ნორმალიზებული პროცესორის ძაფების რაოდენობით 1-ზე მეტია, ეს იმაზე მეტყველებს, რომ Linux სერვერი გადატვირთულია რაღაცით.

რას ელოდება მთელი ეს პროცესი? აშკარა პასუხი არის პროცესორი. მაგრამ პასუხი არ არის მთლად სწორი, რადგან ზოგჯერ პროცესორი უფასოა, მაგრამ LA სცილდება მასშტაბებს. გახსოვდეთ როგორ იშლება NFS და როგორ იზრდება LA. იგივე შეიძლება მოხდეს დისკთან და სხვა შემავალ/გამომავალ მოწყობილობებთან დაკავშირებით. მაგრამ სინამდვილეში, პროცესებს შეუძლიათ დაელოდონ ნებისმიერი დაბლოკვის დასრულებას, ან ფიზიკურს, რომელიც ასოცირდება I/O მოწყობილობასთან, ან ლოგიკურად, როგორიცაა mutex. ეს ასევე მოიცავს დაბლოკვას ტექნიკის დონეზე (იგივე პასუხი დისკიდან) ან ლოგიკა (ე.წ. ჩაკეტვის პრიმიტივები, რომელიც მოიცავს ერთეულების თაიგულს, mutex ადაპტირებულ და სპინს, სემაფორებს, მდგომარეობის ცვლადებს, rw საკეტებს, ipc საკეტებს. ...).

LA-ს კიდევ ერთი მახასიათებელია ის, რომ იგი განიხილება როგორც ოპერაციული სისტემის საშუალო. მაგალითად, 100 პროცესი ეჯიბრება ერთ ფაილს და შემდეგ LA=50. ასეთი დიდი მნიშვნელობა, როგორც ჩანს, მიუთითებს იმაზე, რომ ოპერაციული სისტემა ცუდია. მაგრამ სხვა არასწორად დაწერილი კოდისთვის, ეს შეიძლება იყოს ნორმალური მდგომარეობა, იმისდა მიუხედავად, რომ მხოლოდ ის არის ცუდი და ოპერაციული სისტემაში სხვა პროცესები არ იტანჯება.

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

3. სპეციალური ეფექტები

ახლა გადავხედოთ ქურდობის ძირითად შემთხვევებს, რომლებიც შეგვხვდა. მე გეტყვით, თუ როგორ მოჰყვება ისინი ყოველივე ზემოთქმულს და როგორ უკავშირდება ჰიპერვიზორის ინდიკატორებს.

გადამუშავება. უმარტივესი და ყველაზე გავრცელებული: ჰიპერვიზორი ხელახლა იქნა გამოყენებული. მართლაც, ბევრია გაშვებული ვირტუალური მანქანა, მათში პროცესორის მაღალი მოხმარება, დიდი კონკურენცია, LA უტილიზაცია 1-ზე მეტია (ნორმალიზებული პროცესორის ძაფებით). ყველა ვირტუალურ აპარატში ყველაფერი ნელდება. ასევე იზრდება ჰიპერვიზორიდან გადაცემული ქურდობა, საჭიროა დატვირთვის გადანაწილება ან ვინმეს გამორთვა. ზოგადად, ყველაფერი ლოგიკური და გასაგებია.

პარავირტუალიზაცია ცალკეული შემთხვევების წინააღმდეგ. ჰიპერვიზორზე არის მხოლოდ ერთი ვირტუალური მანქანა; ის მოიხმარს მის მცირე ნაწილს, მაგრამ აწარმოებს დიდ I/O დატვირთვას, მაგალითად დისკზე. და სადღაც მასში ჩნდება პატარა ქურდობა, 10%-მდე (როგორც რამდენიმე ექსპერიმენტმა აჩვენა).

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

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

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

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

დაბალი LA, მაგრამ არის ქურდობა. თუ LA არის დაახლოებით 0,7 (ანუ ჰიპერვიზორი, როგორც ჩანს, დატვირთულია), მაგრამ ქურდობა შეინიშნება ცალკეულ ვირტუალურ მანქანებში:

• პარავირტუალიზაციის პარამეტრი უკვე აღწერილია ზემოთ. ვირტუალურ მანქანას შეუძლია მიიღოს მეტრიკა, რომელიც მიუთითებს მოპარვას, თუმცა ჰიპერვიზორი კარგია. ჩვენი ექსპერიმენტების შედეგების მიხედვით, მოპარვის ეს ვარიანტი არ აღემატება 10% -ს და არ უნდა ჰქონდეს მნიშვნელოვანი გავლენა ვირტუალური მანქანის შიგნით აპლიკაციების შესრულებაზე.
• LA პარამეტრი გამოითვლება არასწორად. უფრო ზუსტად, თითოეულ კონკრეტულ მომენტში ის სწორად არის გათვლილი, მაგრამ როდესაც საშუალოდ ერთ წუთზე აფასებენ, ის არ არის შეფასებული. მაგალითად, თუ ჰიპერვიზორის მესამედზე ერთი ვირტუალური მანქანა მოიხმარს მის ყველა პროცესორს ზუსტად ნახევარი წუთის განმავლობაში, მაშინ LA წუთში ჰიპერვიზორზე იქნება 0,15; ოთხი ასეთი ვირტუალური მანქანა ერთდროულად მუშაობს 0,6-ს. და ის ფაქტი, რომ ნახევარი წუთის განმავლობაში თითოეულ მათგანზე იყო ველური ქურდობა LA ინდიკატორის მიხედვით 25% -ით, აღარ შეიძლება ამოღებული.
• ისევ და ისევ, განრიგის გამო, რომელმაც გადაწყვიტა, რომ ვიღაც ზედმეტად ბევრს ჭამდა და ამ ვიღაცას დაელოდა. ამასობაში, მე შევცვლი კონტექსტს, გავუმკლავდები შეფერხებებს და ვიზრუნებ სისტემის სხვა მნიშვნელოვან საკითხებზე. შედეგად, ზოგიერთი ვირტუალური მანქანა ვერ ხედავს რაიმე პრობლემას, ხოლო სხვები განიცდიან მუშაობის სერიოზულ დეგრადაციას.

4. სხვა დამახინჯებები

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

არსებობს დამახინჯება ისეთი ტექნოლოგიების გამო, როგორიცაა ტურბო გამაძლიერებელი ან, პირიქით, ენერგიის დაზოგვის რეჟიმი, რომელსაც უტილიზაციის გამოთვლისას შეუძლია ხელოვნურად გაზარდოს ან შეამციროს სიხშირე ან თუნდაც დროის მონაკვეთი სერვერზე. ტურბო გამაძლიერებლის ჩართვა ამცირებს ერთი პროცესორის ძაფის მუშაობას მეორის მუშაობის გაზრდის გამო. ამ მომენტში, ინფორმაცია მიმდინარე პროცესორის სიხშირის შესახებ არ გადაეცემა ვირტუალურ მანქანას და მას მიაჩნია, რომ ვიღაც იპარავს მის დროს (მაგალითად, მან მოითხოვა 2 გჰც, მაგრამ მიიღო ამის ნახევარი).

ზოგადად, დამახინჯების მრავალი მიზეზი შეიძლება იყოს. თქვენ შეგიძლიათ იპოვოთ რაიმე სხვა კონკრეტულ სისტემაზე. ჯობია დავიწყოთ იმ წიგნებით, რომლებზეც ზემოთ მივეცი ლინკები და ჰიპერვიზორიდან სტატისტიკის მოძიება ისეთი კომუნალური საშუალებების გამოყენებით, როგორიცაა perf, sysdig, systemtap, რომელთაგან ათობით.

5. დასკვნები

1. გარკვეული რაოდენობის მოპარვა შეიძლება მოხდეს პარავირტუალიზაციის გამო და ეს შეიძლება ნორმალურად ჩაითვალოს. ინტერნეტში წერენ, რომ ეს მნიშვნელობა შეიძლება იყოს 5-10%. ეს დამოკიდებულია ვირტუალური მანქანის შიგნით არსებულ აპლიკაციებზე და დატვირთვაზე, რომელსაც ის აყენებს მის ფიზიკურ მოწყობილობებზე. აქ მნიშვნელოვანია ყურადღება მიაქციოთ იმას, თუ როგორ გრძნობენ თავს აპლიკაციები ვირტუალურ აპარატებში.
2. ჰიპერვიზორზე დატვირთვისა და ვირტუალური მანქანის შიგნით მოპარვის თანაფარდობა ყოველთვის არ არის მკაფიოდ ურთიერთდაკავშირებული; მოპარვის ორივე შეფასება შეიძლება იყოს მცდარი კონკრეტულ სიტუაციებში სხვადასხვა დატვირთვის ქვეშ.
3. განრიგს აქვს ცუდი დამოკიდებულება იმ პროცესების მიმართ, რომლებიც ბევრს ითხოვენ. ის ცდილობს ნაკლები მისცეს მათ, ვინც მეტს ითხოვს. დიდი ვირტუალური მანქანები ბოროტებაა.
4. მცირე მოპარვა შეიძლება იყოს ნორმა პარავირტუალიზაციის გარეშეც (ვირტუალური მანქანის შიგნით დატვირთვის, მეზობლების დატვირთვის მახასიათებლების, ძაფებზე დატვირთვის განაწილების და სხვა ფაქტორების გათვალისწინებით).
5. თუ გსურთ გაიგოთ ქურდობა კონკრეტულ სისტემაში, უნდა შეისწავლოთ სხვადასხვა ვარიანტები, შეაგროვოთ მეტრიკა, ყურადღებით გაანალიზოთ ისინი და იფიქროთ იმაზე, თუ როგორ თანაბრად გადაანაწილოთ დატვირთვა. შესაძლებელია ნებისმიერი შემთხვევიდან გადახრები, რაც უნდა დადასტურდეს ექსპერიმენტულად ან ჩახედული იყოს ბირთვის გამართვაში.

წყარო: www.habr.com