Готов за процесора: Безшумният убиец на хипервизор

CPU Ready е нещо, с което може да не сте запознати. На първо впечатление може да звучи като нещо добро, но за съжаление не е така. CPU Ready измъчва виртуални среди по-дълго, отколкото знаехме какво е това. VMware определя това като „Процент от времето, през което виртуалната машина е била готова, но не може да получи график за изпълнение на физическия процесор. Времето за готовност на процесора зависи от броя на виртуалните машини на хоста и техните зареждания на процесора. ' Hyper-V едва наскоро започна да предоставя този брояч (Виртуален процесор Hyper-V Hypervisor CPU Време за изчакване на изпращане) и други хипервизори все още може да не предоставят тази метрика.

За да разберем какво е CPU Ready, ще трябва да разберем как хипервизорите планират виртуални CPU (vCPU) към физически CPU (pCPU). Когато времето на vCPU е необходимо във VM, това е vCPU (и) трябва да бъдат насрочени срещу pCPU (и), така че командите / процесите / нишките да могат да се изпълняват срещу pCPU. В идеалния свят няма конфликти на ресурси или тесни места, когато това трябва да се случи. Когато една vCPU VM трябва да планира време спрямо pCPU, налично е pCPU ядро ​​и CPU Ready е много минимално в този идеален свят. Важно е да се отбележи, че CPU Ready винаги съществува, но в идеалния свят той е много минимален и не се забелязва.

В реалния свят едно от предимствата на виртуализацията е, че можете да се обзаложите, че много от вашите виртуални машини няма да добавят всичките си vCPU едновременно и ако те са с много ниска употреба на виртуални машини, може дори да предположите колко можете заредете физическия си хост въз основа на използването на процесора и използването на RAM. В миналото бяха отправени препоръки да има 4 vCPU към 1 pCPU или дори съотношение 10: 1 в зависимост от натоварването. Например, може да имате един четириядрен процесор, но да имате 4 виртуални машини с vCPU, всяка за да ви даде 16 vCPU на 4 pCPU или 4: 1. Това, което инженерите започнаха да виждат обаче, е, че средата беше просто ужасно бавна и те не можаха да разберат защо. Използването на RAM изглеждаше добре, използването на процесора на физическите хостове може дори да е много ниско, под 20%. Латентността на съхранението беше изключително ниска, но виртуалните машини бяха изключително бавни.

Това, което се случваше в този сценарий, беше CPU Ready. Имаше изграждане на опашка от vCPU, готов да бъде насрочен, но няма наличен pCPU за планиране. Хипервизорът ще забави планирането и ще предизвика латентност за виртуалната машина за гости. Тих убиец е, че до последните години нямаше много инструменти за откриване. В Windows VM ще отнеме вечно зареждане и след това, когато най-накрая го направи, когато щракнете върху менюто 'Старт', ще отнеме вечно, за да се покаже. Можете дори да го щракнете отново, мислейки, че не е приел първото ви щракване и когато най-накрая навакса, ще получите двойно щракване. В Linux вашата VM може да се зареди в режим само за четене или дори да превключи файловите системи в режим само за четене в даден момент по-късно.

И така, как да се борим с CPU Ready? Има няколко начина, които могат да помогнат. Първият е мониторинг на показателите за готовност на процесора. Във VMware не се препоръчва да надхвърляте 10%, но в личен опит потребителите започват да забелязват над 5-7% в зависимост от вида на VM и какво работи.

По-долу ще използвам няколко примера от VMware ESXi 5.5, за да покажа CPU Ready. Използвайки командния ред, стартирайте “esxtop”. Натиснете „c“ за изглед на процесора и ще видите колона „ % RDY ”За CPU Ready. Можете да натиснете капитала “ V ”Само за изглед на виртуална машина.

Тук можете да видите, че% RDY е малко висок за доста неизползвана среда. В този случай моят ESXi 5.5 изпълнява тестова виртуална машина на върха на VMware Fusion (Mac хипервизор), така че се очаква да е малко по-висок, тъй като изпълняваме VM на хипервизор върху друг хипервизор.

В клиента vSphere можете да извадите конкретната виртуална машина и да кликнете върху раздела Производителност. Оттам кликнете върху „Опции на диаграмата“

В Опции на диаграмата изберете CPU, в реално време (ако имате vCenter, може да имате и други опции за синхронизация освен в реално време). От там в броячите изберете „Готово“. Може да се наложи да отмените избора на различен брояч, тъй като изгледът позволява само два типа данни по всяко време.

Ще забележите, че тази стойност е обобщение на готовност спрямо процент. Ето връзка към статия на VMware KB за това как да конвертирате обобщените показатели в процент. - https://kb.vmware.com/kb/2002181

Когато купувате хардуер, повече ядра помагат за намаляване на въздействието на CPU Ready. Hyperthreading също помага. Докато Hyperthreading не осигурява пълно второ ядро ​​за всяко основно ядро, обикновено е достатъчно, за да позволи планирането на vCPU към pCPU и да помогне за смекчаване на проблема. Въпреки че хипервизорите започват да се отдалечават от препоръката за съотношение vCPU към pCPU, обикновено можете да се справите добре в умерено използвана среда с 4: 1 и да отидете от там. Когато започнете да зареждате виртуални машини, погледнете латентността на процесора, готовността на процесора и цялостното усещане и производителност. Ако имате някои удрящи виртуални машини, може да искате да ги разделите на други клъстери и да използвате по-ниско съотношение и да ги поддържате леки. От друга страна, за виртуални машини, където производителността не е ключова и е добре за тях да работят бавно, можете да се абонирате много по-високо.

Адекватното оразмеряване на виртуалните машини също е огромен инструмент за борба с CPU Ready. Много доставчици препоръчват спецификации много повече от това, което VM може действително да се нуждае. Традиционно повече процесори и повече ядра = повече мощност. Проблемът във виртуалната среда е, че хипервизорът трябва да планира всички vCPU към pCPU приблизително по едно и също време и заключването на pCPU може да бъде проблематично. Ако имате 8 vCPU VM, трябва да заключите 8 pCPU, за да им позволите да планират едновременно. Ако вашата vCPU VM използва само 10% от общия vCPU във всеки един момент, по-добре е да намалите vCPU отброяването до 2 или 4. По-добре е да стартирате VM с 50-80% CPU с по-малко vCPU от 10% при повече vCPU. Този проблем е отчасти защото плановият процесор на операционната система е проектиран да използва колкото се може повече ядра, докато ако е бил обучен да максимизира ядра, преди да използва повече, това може да е по-малък проблем. Една извънгабаритна виртуална машина може да се представя добре, но може да бъде „шумен съсед“ за други виртуални машини, така че обикновено е процес, при който трябва да преминете през всички виртуални машини в клъстера, за да ги „правилно оразмерите“, за да видите някои подобрения в производителността.

Много пъти сте се сблъсквали с CPU Ready и е трудно да започнете правилно оразмеряване на виртуални машини или надграждане до процесори с повече ядра. Ако сте в тази ситуация, добавянето на повече хостове във вашия клъстер може да помогне с това за разпределяне на товара върху повече хостове. Ако имате хостове с повече ядра / процесори от други, прикачването на високи vCPU виртуални машини към тези по-високи ядра също може да помогне. Искате да гарантирате, че вашият физически хост има поне същия брой ядра, ако не повече от VM, в противен случай ще бъде много бавно / трудно да планирате излишъка от vCPU към pCPU, тъй като те трябва да бъдат заключени приблизително по едно и също време .

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

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