Кражба: кой краде процесорно време от виртуални машини

Здравейте! Искам да разкажа с прости думи за механиката на появата на steal във виртуалните машини и за някои неочевидни артефакти, които успяхме да открием по време на неговото изследване, в което трябваше да се потопя като технически директор на облачна платформа Облачни решения на Mail.ru. Платформата работи на KVM.

CPU steal time е времето, през което виртуалната машина не получава процесорни ресурси за своето изпълнение. Това време се взема предвид само в гост операционни системи във виртуализационни среди. Причините за това къде отиват тези разпределени ресурси, както в живота, са много неясни. Но ние решихме да го разберем, дори поставихме няколко експеримента. Не че сега знаем всичко за кражбата, но сега ще ви кажем нещо интересно.

1. Какво е кражба

И така, steal е показател, който показва липсата на процесорно време за процеси във виртуална машина. Както е описано в корекцията на ядрото на KVM, steal е времето, през което хипервайзорът изпълнява други процеси на хост ОС, въпреки че е поставил процеса на виртуална машина на опашка за изпълнение. Тоест кражбата се изчислява като разликата между времето, когато процесът е готов за изпълнение, и времето, когато на процеса е разпределено процесорно време.

Ядрото на виртуалната машина получава метриката за кражба от хипервайзора. В същото време хипервайзорът не уточнява какви други процеси изпълнява, просто „докато съм зает, не мога да ви отделя време“. В KVM е добавена поддръжка за изчисляване на кражба лепенки. Тук има два ключови момента:

• Виртуалната машина научава за кражба от хипервайзора. Тоест, от гледна точка на загубите, за процесите на самата виртуална машина, това е косвено измерване, което може да бъде обект на различни изкривявания.
• Хипервайзорът не споделя информация с виртуалната машина какво друго прави - основното е, че не отделя време за това. Поради това самата виртуална машина не може да открие изкривявания в индикатора за кражба, които биха могли да бъдат оценени от естеството на конкуриращи се процеси.

2. Какво влияе на кражбата

2.1. Изчисление за кражба

Всъщност кражбата се разглежда почти по същия начин като обичайното време за използване на процесора. Няма много информация за това как се разглежда рециклирането. Вероятно защото мнозинството смята този въпрос за очевиден. Но и тук има подводни камъни. За общ преглед на този процес прочетете статия от Брендън Грег: ще научите за куп нюанси при изчисляване на използването и за ситуации, когато това изчисление ще бъде погрешно поради следните причини:

• Прегряване на процесора, при което се пропускат цикли.
• Активиране/деактивиране на турбо усилване, което променя тактовата честота на процесора.
• Промяна в дължината на времеви отрязък, която възниква при използване на енергоспестяващи технологии на процесора като SpeedStep.
• Изчисляване на средния проблем: едноминутна оценка на използване от 80% може да скрие краткосрочен взрив от 100%.
• Заключването на завъртане кара процесора да бъде възстановен, но потребителският процес не вижда напредък в изпълнението си. В резултат на това очакваното използване на процесора от процеса ще бъде XNUMX%, въпреки че процесът физически няма да изразходва процесорно време.

Не намерих статия, описваща подобно изчисление за кражба (ако знаете, споделете го в коментарите). Но, съдейки по източниците, механизмът за изчисление е същият като при рециклирането. Просто в ядрото е добавен още един брояч, директно за KVM процеса (процес на виртуална машина), който отчита продължителността на KVM процеса в състояние на изчакване на процесорното време. Броячът взема информация за процесора от неговата спецификация и вижда дали всичките му отметки се използват от процеса на виртуалната машина. Ако всичко, тогава считаме, че процесорът е бил ангажиран само в процеса на виртуалната машина. В противен случай информираме, че процесорът е правил нещо друго, появи се кражба.

Процесът на броене на кражби е обект на същите проблеми като нормалния брой на кражбите. Да не кажа, че подобни проблеми се появяват често, но изглеждат обезкуражаващи.

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, а опит да се привлече вниманието към факта, че "справедливото" разпределение на процесорното време не е най-тривиалната задача.

Друг важен момент в планировчика е изпреварването. Това е необходимо, за да изгоните процеса на snickering от процесора и да оставите другите да работят. Процесът на изгонване се нарича контекстно превключване, превключване на контекста на процесора. В същото време се запазва целият контекст на задачата: състоянието на стека, регистрите и т.н., след което процесът се изпраща да изчака и друг заема неговото място. Това е скъпа операция за операционната система и рядко се използва, но всъщност няма нищо лошо в това. Честото превключване на контекст може да показва проблем в операционната система, но обикновено продължава непрекъснато и не показва нищо конкретно.

Такава дълга история е необходима, за да се обясни един факт: колкото повече процесорни ресурси се опитва да изразходва един процес в един честен планировчик на Linux, толкова по-бързо ще бъде спрян, за да могат и други процеси да работят. Дали това е правилно или не е труден въпрос, който се решава по различен начин при различни натоварвания. В Windows доскоро планировчикът беше фокусиран върху приоритетната обработка на настолни приложения, което може да доведе до спиране на фоновите процеси. Sun Solaris имаше пет различни класа програмисти. При стартирането на виртуализацията беше добавена шеста, справедлив дял планировчикзащото предишните пет не работеха адекватно с виртуализацията на Solaris Zones. Препоръчвам да започнете подробно проучване на този въпрос с книги като Вътрешни елементи на Solaris: Solaris 10 и OpenSolaris Kernel Architecture или Разбиране на Linux ядрото.

2.4. Как да наблюдавате кражбата?

Мониторингът на кражба във виртуална машина, подобно на всяка друга метрика на процесора, е прост: можете да използвате всеки инструмент за метрика на процесора. Основното нещо е виртуалната машина да е на Linux. По някаква причина Windows не предоставя такава информация на своите потребители. 🙁

Резултатът от горната команда: подробно натоварване на процесора, в най-дясната колона - кражба

Трудността възниква, когато се опитвате да получите тази информация от хипервайзора. Можете да опитате да предскажете кражба на хост машината, например чрез параметъра Load Average (LA) - средната стойност на броя процеси, чакащи в опашката за изпълнение. Методът за изчисляване на този параметър не е прост, но като цяло, ако LA, нормализиран от броя на процесорните нишки, е по-голям от 1, това показва, че Linux сървърът е претоварен с нещо.

Какво чакат всички тези процеси? Очевидният отговор са процесорите. Но отговорът не е съвсем правилен, защото понякога процесорът е безплатен и LA излиза извън мащаба. Помня как NFS пада и как LA расте в същото време. Приблизително същото може да бъде с диска и с други входно / изходни устройства. Но всъщност процесите могат да изчакат края на всяко заключване, както физическо, свързано с I / O устройството, така и логическо, като мютекс. Той също така включва ключалки на хардуерно ниво (същият отговор от диска) или логика (така наречените заключващи примитиви, които включват куп обекти, mutex adaptive и spin, семафори, променливи на условието, rw ключалки, ipc ключалки. ..).

Друга особеност на LA е, че се приема като средна стойност за операционната система. Например 100 процеса се конкурират за един файл и след това LA=50. Такава голяма стойност, изглежда, показва, че операционната система е лоша. Но за друг криво написан код това може да е нормално състояние, въпреки факта, че само то е лошо и други процеси в операционната система не страдат.

Поради това осредняване (и не по-малко от минута), определянето на каквото и да било по отношение на LA не е най-възнаграждаващата задача, с много несигурни резултати в конкретни случаи. Ако се опитате да го разберете, ще откриете, че статиите в Wikipedia и други налични ресурси описват само най-простите случаи, без задълбочено обяснение на процеса. Изпращам на всички заинтересовани отново, тук за Брендан Грег  - следвайте връзките. Кой е мързелив на английски - превод на популярната му статия за Ел Ей.

3. Специални ефекти

Сега нека се спрем на основните случаи на кражба, с които се сблъскахме. Ще ви кажа как те следват от всичко по-горе и как корелират с индикаторите на хипервайзора.

Рециклиране. Най-простият и най-често срещаният: хипервайзорът се рециклира. Наистина има много работещи виртуални машини, висока консумация на процесори вътре в тях, много конкуренция, използване от LA е по-голямо от 1 (нормализирано от нишките на процесора). Вътре във всички virtualok всичко се забавя. Кражбата, предавана от хипервайзора, също расте, необходимо е да се преразпредели натоварването или да се изключи някой. Като цяло всичко е логично и разбираемо.

Паравиртуализация срещу самотни екземпляри. Има само една виртуална машина на хипервайзора, тя консумира малка част от нея, но дава голямо I / O натоварване, например на диск. И отнякъде в него се появява малка кражба, до 10% (както показват няколко експеримента).

Случаят е интересен. Steal се появява тук само поради ключалки на ниво паравиртуализирани драйвери. Във виртуалната машина се създава прекъсване, обработва се от драйвера и отива към хипервайзора. Поради обработка на прекъсване на хипервайзора, това изглежда като изпратена заявка към виртуалната машина, тя е готова за изпълнение и чака процесора, но не й е дадено процесорно време. Виртуалната машина смята, че това време е откраднато.

Това се случва в момента, в който буферът е изпратен, той отива в пространството на ядрото на хипервайзора и ние започваме да го чакаме. Въпреки че, от гледна точка на виртуалната машина, той трябва незабавно да се върне. Следователно, според алгоритъма за изчисляване на кражбата, това време се счита за откраднато. Най-вероятно в тази ситуация може да има други механизми (например обработка на още някои системни повиквания), но те не трябва да се различават много.

Планировчик срещу високо натоварени виртуални машини. Когато една виртуална машина страда от кражба повече от други, това се дължи точно на планировчика. Колкото повече процесът натоварва процесора, толкова по-скоро планировчикът ще го изхвърли, така че останалите също да работят. Ако една виртуална машина консумира малко, тя едва ли ще види кражба: процесът й честно седеше и чакаше, трябва да му се даде повече време. Ако виртуалната машина произвежда максимално натоварване на всичките си ядра, тя по-често се изхвърля от процесора и се опитват да не й дават много време.

Още по-лошо е, когато процесите във виртуалната машина се опитват да получат повече процесор, защото не могат да се справят с обработката на данни. Тогава операционната система на хипервайзора, поради честна оптимизация, ще дава все по-малко процесорно време. Този процес протича като лавина и кражбата скача до небето, въпреки че други виртуални машини едва ли ще го забележат. И колкото повече ядра, толкова по-лоша е машината, която попада под разпространението. Накратко, най-много страдат силно натоварените виртуални машини с много ядра.

Нисък LA, но има кражба. Ако LA е около 0,7 (т.е. хипервайзорът изглежда не е натоварен), но се наблюдава кражба в отделни виртуални машини:

• Вече описаната по-горе опция с паравиртуализация. Виртуалната машина може да получава показатели, показващи кражба, въпреки че хипервайзорът се справя добре. Според резултатите от нашите експерименти тази опция за кражба не надвишава 10% и не би трябвало да има значително влияние върху производителността на приложението във виртуалната машина.
• Параметърът LA се счита за неправилен. По-точно във всеки конкретен момент се счита за правилен, но осреднен за една минута се оказва подценен. Например, ако една виртуална машина на трета от хипервайзора изразходва всичките си процесори точно за половин минута, тогава LA на минута на хипервайзора ще бъде 0,15; четири такива виртуални машини, работещи едновременно, ще дадат 0,6. И това, че за половин минута на всеки от тях имаше wild steal на 25% по отношение на LA, вече не може да се извади.
• Пак заради графика, който реши, че някой яде много и нека този някой да чака. Междувременно ще превключвам контекста, ще обработвам прекъсванията и ще се грижа за други важни системни неща. В резултат на това някои виртуални машини не виждат никакви проблеми, докато други изпитват сериозно влошаване на производителността.

4. Други изкривявания

Има още милион причини за изкривяване на честното връщане на процесорното време на виртуална машина. Например хипернишковостта и NUMA добавят сложност към изчисленията. Те напълно объркват избора на ядрото за изпълнение на процеса, тъй като планировчикът използва коефициенти - тегла, които при превключване на контекста правят изчислението още по-трудно.

Има изкривявания, дължащи се на технологии като турбоусилване или, обратно, режим на пестене на енергия, които при изчисляване на използването могат изкуствено да увеличат или намалят честотата или дори кванта на времето на сървъра. Активирането на Turbo Boost намалява производителността на една процесорна нишка поради увеличаване на производителността на друга. В този момент информацията за текущата честота на процесора не се предава на виртуалната машина и тя смята, че някой й краде времето (например поиска 2 GHz, но получи наполовина по-малко).

Като цяло може да има много причини за изкривявания. В определена система може да намерите нещо друго. По-добре е да започнете с книгите, към които дадох връзки по-горе, и четене на статистики от хипервайзора с помощни програми като perf, sysdig, systemtap, от които десетки.

5. Заключения

1. Известно количество кражба може да възникне поради паравиртуализация и може да се счита за нормално. В интернет пишат, че тази стойност може да бъде 5-10%. Зависи от приложенията във виртуалната машина и от това какво натоварване дава на своите физически устройства. Тук е важно да обърнете внимание как се чувстват приложенията във виртуални машини.
2. Съотношението на натоварването на хипервайзора и кражбата във виртуалната машина не винаги е недвусмислено взаимосвързано, и двете оценки на кражбата могат да бъдат погрешни в конкретни ситуации при различни натоварвания.
3. Планировчикът има лошо отношение към процесите, които изискват много. Той се опитва да даде по-малко на тези, които искат повече. Големите виртуални машини са зли.
4. Малка кражба може да бъде норма дори без паравиртуализация (като се вземе предвид натоварването във виртуалната машина, характеристиките на натоварването на съседите, разпределението на натоварването между нишките и други фактори).
5. Ако искате да разберете кражбата на конкретна система, трябва да проучите различни опции, да съберете показатели, да ги анализирате внимателно и да помислите как да разпределите равномерно натоварването. Възможни са отклонения от всякакви случаи, които трябва да бъдат потвърдени експериментално или погледнати в дебъгера на ядрото.

Източник: www.habr.com