Ако администрирате виртуална инфраструктура, базирана на VMware vSphere (или друг технологичен стек), вероятно често чувате оплаквания от потребители: „Виртуалната машина е бавна!“. В тази поредица от статии ще анализирам показателите за ефективност и ще ви кажа какво и защо „се забавя“ и как да се уверите, че не „се забавя“.
Ще разгледам следните аспекти на производителността на виртуалната машина:
- CPU,
- RAM,
- диск,
- Network.
Ще започна с процесора.
За анализ на ефективността ни трябва:
- Броячи на производителността на vCenter – броячи на производителност, чиито графики могат да се видят през vSphere Client. Информацията за тези броячи е достъпна във всяка версия на клиента („дебел“ клиент в C#, уеб клиент във Flex и уеб клиент в HTML5). В тези статии ще използваме екранни снимки от C# клиента, просто защото изглеждат по-добре в миниатюра :)
- ESXTOP е помощна програма, която се изпълнява от командния ред на ESXi. С негова помощ можете да получите стойностите на броячите на производителност в реално време или да качите тези стойности за определен период в .csv файл за по-нататъшен анализ. След това ще ви разкажа повече за този инструмент и ще предоставя някои полезни връзки към документация и статии по темата.
Малко теория
В ESXi отделен процес отговаря за работата на всеки vCPU (ядро на виртуална машина) - свят в терминологията на VMware. Има и обслужващи процеси, но от гледна точка на анализа на производителността на VM те са по-малко интересни.
Процесът в ESXi може да бъде в едно от четирите състояния:
- бягане Процесът върши полезна работа.
- Чакам - процесът не извършва никаква работа (бездейства) или чака вход / изход.
- Костоп - състояние, което възниква в многоядрени виртуални машини. Това се случва, когато CPU планировчикът на хипервайзора (ESXi CPU Scheduler) не може да планира всички активни ядра на виртуална машина да работят на физическите ядра на сървъра едновременно. Във физическия свят всички процесорни ядра работят паралелно, ОС за гости във VM очаква подобно поведение, така че хипервайзорът трябва да забави VM ядрата, които имат възможност да завършат цикъла по-бързо. В съвременните версии на ESXi планировчикът на процесора използва механизъм, наречен релаксирано съвместно планиране: хипервайзорът изчислява разликата между „най-бързото“ и „най-бавното“ ядро на виртуалната машина (изкривяване). Ако празнината надвиши определен праг, "бързото" ядро влиза в състояние на костоп. Ако VM ядрата прекарват много време в това състояние, това може да причини проблеми с производителността.
- Готов – процесът влиза в това състояние, когато хипервайзорът не може да разпредели ресурси за неговото изпълнение. Високите готови стойности могат да причинят проблеми с производителността на VM.
Основни броячи на производителност на VM CPU
Използване на процесора, %. Показва процента на използване на процесора за посочения период.
Как да анализираме? Ако виртуалната машина постоянно използва процесора на 90% или има пикове до 100%, тогава имаме проблем. Проблемите могат да се изразяват не само в "бавната" работа на приложението вътре във VM, но и в недостъпността на VM през мрежата. Ако системата за наблюдение показва, че VM периодично пада, обърнете внимание на пиковете на графиката за използване на процесора.
Има стандартна аларма, която показва натоварването на процесора на виртуалната машина:
Какво да правя? Ако използването на процесора на виртуалната машина постоянно надвишава мащаба, тогава можете да помислите за увеличаване на броя на vCPU (за съжаление, това не винаги помага) или за преместване на виртуалната машина към сървър с по-ефективни процесори.
Използване на процесора в Mhz
В графиките на vCenter, Използването в % може да се види само за цялата виртуална машина, няма графики за отделни ядра (в Esxtop има стойности в % за ядра). За всяко ядро можете да видите Използване в MHz.
Как да анализираме? Случва се приложението да не е оптимизирано за многоядрена архитектура: използва само едно ядро на 100%, а останалите са неактивни без натоварване. Например, с настройките по подразбиране за архивиране, MS SQL стартира процеса само на едно ядро. В резултат на това архивирането се забавя не поради ниската скорост на дисковете (това е, от което потребителят първоначално се оплаква), а защото процесорът не може да се справи. Проблемът беше решен чрез промяна на параметрите: архивирането започна да работи паралелно в няколко файла (съответно в няколко процеса).
Пример за неравномерно натоварване на ядра.
Има и ситуация (както на графиката по-горе), когато ядрата са натоварени неравномерно и някои от тях имат пикове от 100%. Както при зареждане само на едно ядро, алармата за използване на процесора няма да работи (тя е в цялата виртуална машина), но ще има проблеми с производителността.
Какво да правя? Ако софтуерът във виртуалната машина натоварва ядрата неравномерно (използва само едно ядро или част от ядрата), няма смисъл да увеличавате броя им. В този случай е по-добре да преместите виртуалната машина на сървър с по-ефективни процесори.
Можете също да опитате да проверите настройките на захранването в BIOS на сървъра. Много администратори активират режима High Performance в BIOS и по този начин деактивират технологиите за пестене на енергия C-states и P-states. Съвременните процесори на Intel използват технологията Turbo Boost, която увеличава честотата на отделните процесорни ядра за сметка на други ядра. Но работи само когато са активирани енергоспестяващи технологии. Ако ги деактивираме, тогава процесорът не може да намали консумацията на енергия на ядра, които не са натоварени.
VMware препоръчва да не деактивирате енергоспестяващите технологии на сървърите, а да изберете режими, които дават максимално управление на захранването на хипервайзора. В същото време в настройките за консумация на енергия на хипервизора трябва да изберете Висока производителност.
Ако имате отделни VM (или VM ядра) във вашата инфраструктура, които изискват повишена честота на процесора, правилното конфигуриране на консумацията на енергия може значително да подобри тяхната производителност.
CPU Ready (Готовност)
Ако VM ядрото (vCPU) е в състояние на готовност, то не извършва полезна работа. Това състояние възниква, когато хипервайзорът не намери свободно физическо ядро, към което може да бъде присвоен vCPU процесът на виртуалната машина.
Как да анализираме? Обикновено, ако ядрата на виртуална машина са в състояние на готовност за повече от 10% от времето, тогава ще забележите проблеми с производителността. Просто казано, повече от 10% от времето VM чака наличността на физически ресурси.
Във vCenter можете да видите 2 брояча, свързани с CPU Ready:
- готовност,
- Готов.
Стойностите на двата брояча могат да се видят както за цялата виртуална машина, така и за отделни ядра.
Готовността показва стойността веднага като процент, но само в реално време (данни за последния час, интервал на измерване 20 секунди). Този брояч се използва най-добре само за намиране на проблеми по горещо преследване.
Готовите стойности на брояча могат да се разглеждат и в историческа перспектива. Това е полезно за установяване на модели и за по-задълбочен анализ на проблема. Например, ако VM започне да има проблеми с производителността в определен момент, можете да сравните интервалите на задържане на CPU Ready с общото натоварване на сървъра, където работи VM, и да предприемете стъпки за намаляване на натоварването (ако DRS не успее).
Готовността, за разлика от готовността, се показва не в проценти, а в милисекунди. Това е брояч от типа Summation, т.е. той показва колко време през периода на измерване VM ядрото е било в състояние Ready. Можете да конвертирате тази стойност в процент с помощта на проста формула:
(Сумирана стойност на готовност на процесора / (интервал за актуализиране по подразбиране на диаграмата в секунди * 1000)) * 100 = % готовност на процесора
Например за VM в графиката по-долу пиковата стойност на Ready за цялата виртуална машина ще бъде:
Когато изчислявате стойността на готовност като процент, трябва да обърнете внимание на две точки:
- Стойността Ready за цялата VM е сумата от Ready за ядрата.
- Интервал на измерване. За реално време това са 20 секунди, а например на дневни графики това са 300 секунди.
С активно отстраняване на неизправности, тези прости моменти могат лесно да бъдат пропуснати и ценно време да бъде загубено за решаване на несъществуващи проблеми.
Нека изчислим Ready въз основа на данните от графиката по-долу. (324474/(20*1000))*100 = 1622% за цялата VM. Ако погледнете ядрата, не е толкова страшно: 1622/64 = 25% на ядро. В този случай уловката е доста лесна за забелязване: стойността Ready е нереалистична. Но ако говорим за 10–20% за цялата виртуална машина с няколко ядра, тогава за всяко ядро стойността може да бъде в рамките на нормалния диапазон.
Какво да правя? Високата стойност на Ready показва, че сървърът няма достатъчно процесорни ресурси за нормалната работа на виртуалните машини. В такава ситуация остава само да се намали свръхабонаментът по процесор (vCPU:pCPU). Очевидно това може да се постигне чрез намаляване на параметрите на съществуващите виртуални машини или чрез мигриране на част от виртуалната машина към други сървъри.
Съвместно спиране
Как да анализираме? Този брояч също има тип Сумиране и се преобразува в проценти по същия начин като Готов:
(Сумирана стойност на съвместното спиране на процесора / (интервал за актуализиране по подразбиране на диаграмата в секунди * 1000)) * 100 = % на съвместното спиране на процесора
Тук също трябва да обърнете внимание на броя ядра на VM и интервала на измерване.
В състояние на костоп ядрото не извършва полезна работа. При правилно оразмеряване на виртуална машина и нормално натоварване на сървъра, броячът за съвместно спиране трябва да е близо до нула.
В този случай натоварването е очевидно ненормално :)
Какво да правя? Ако няколко виртуални машини с голям брой ядра работят на един и същ хипервайзор и има свръхабонамент от процесора, тогава броячът за съвместно спиране може да се увеличи, което ще доведе до проблеми с производителността на тези виртуални машини.
Освен това съвместното спиране ще се увеличи, ако нишките се използват за активни ядра на една виртуална машина на едно ядро на физически сървър с активирано хипер-настъпване. Тази ситуация може да възникне, например, ако VM има повече ядра, отколкото физически има на сървъра, където работи, или ако настройката „preferHT“ е активирана за VM. Можете да прочетете за тази настройка. .
За да избегнете проблеми с производителността на VM, дължащи се на високи ко-стопове, оразмерете VM според препоръките на производителя за софтуера, който работи на тази VM, и възможностите на физическия сървър, на който работи VM.
Не добавяйте ядра в резерв, това може да причини проблеми с производителността не само на самата виртуална машина, но и на нейните съседи на сървъра.
Други полезни показатели за процесора
бягане – колко дълго (ms) по време на периода на измерване vCPU е бил в състояние RUN, тоест действително е извършил полезна работа.
Режим – колко време (ms) по време на периода на измерване vCPU е бил в неактивно състояние. Високите стойности на празен ход не са проблем, просто vCPU няма „нищо общо“.
Чакам – колко дълго (ms) по време на периода на измерване vCPU е бил в състояние на изчакване. Тъй като IDLE е включен в този брояч, високите стойности на Wait също не означават проблем. Но ако Wait IDLE е ниско, когато е високо, тогава VM е чакал завършването на I / O операции и това от своя страна може да показва проблем с производителността на твърдия диск или всякакви виртуални устройства на VM.
Максимално ограничено – колко дълго (ms) по време на периода на измерване vCPU е бил в състояние Ready поради зададения лимит на ресурса. Ако производителността е необяснимо ниска, тогава е полезно да проверите стойността на този брояч и ограничението на процесора в настройките на VM. Виртуалните машини може наистина да имат ограничения, за които не знаете. Например, това се случва, когато VM е клониран от шаблон, който има ограничение за CPU, зададено върху него.
Разменете изчакване – колко дълго през периода на измерване vCPU е чакал операция с VMkernel Swap. Ако стойността на този брояч е над нула, тогава VM определено има проблеми с производителността. Ще говорим повече за SWAP в статията за RAM броячите.
ESXTOP
Ако броячите на производителност във vCenter са добри за анализиране на исторически данни, тогава онлайн анализът на проблема е по-добре да се направи в ESXTOP. Тук всички стойности са представени в завършен вид (няма нужда да превеждате нищо), а минималният период на измерване е 2 секунди.
Екранът ESXTOP на процесора се извиква с клавиша "c" и изглежда така:
За удобство можете да оставите само процесите на виртуалната машина, като натиснете Shift-V.
За да видите показатели за отделни VM ядра, натиснете "e" и въведете GID на VM, който ви интересува (30919 на екранната снимка по-долу):
Ще прегледам накратко колоните, които са представени по подразбиране. Допълнителни колони могат да се добавят чрез натискане на "f".
NWLD (брой светове) е броят на процесите в групата. За да разширите групата и да видите показатели за всеки процес (например за всяко ядро на многоядрена виртуална машина), натиснете „e“. Ако има повече от един процес в група, тогава показателите за групата са равни на сумата от показателите за отделните процеси.
%ИЗПОЛЗВАНО – колко цикъла на процесора на сървъра използва процес или група от процеси.
% ПУСКАНЕ – колко време през периода на измерване процесът е бил в състояние RUN, т.е. свърши полезна работа. Различава се от %USED по това, че не взема под внимание хипернишковостта, честотното мащабиране и времето, прекарано на системни задачи (%SYS).
%SYS - време, изразходвано за системни задачи, например: обработка на прекъсване, I/O, работа в мрежа и т.н. Стойността може да бъде висока, ако VM има много I/O.
%OVRLP - колко време физическото ядро, на което работи VM процесът, е изразходвало за задачи на други процеси.
Тези показатели са свързани помежду си, както следва:
%USED = %RUN + %SYS - %OVRLP.
Обикновено показателят %USED е по-информативен.
%ИЗЧАКАЙТЕ – колко дълго през периода на измерване процесът е бил в състояние на изчакване. Включва IDLE.
%ПРАЗЕН – колко време през периода на измерване процесът е бил в състояние IDLE.
% SWPWT – колко дълго през периода на измерване vCPU е чакал операция с VMkernel Swap.
%VMWAIT – колко време през периода на измерване vCPU е бил в състояние на изчакване на събитие (обикновено I/O). Във vCenter няма подобен брояч. Високите стойности показват проблеми с I/O на VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Ако VM не използва VMkernel Swap, тогава, когато анализирате проблеми с производителността, препоръчително е да погледнете %VMWAIT, тъй като този показател не взема предвид времето, когато VM не е направила нищо (%IDLE).
%RDY – колко време през периода на измерване процесът е бил в състояние Ready.
%CSTP – колко дълго през периода на измерване процесът е бил в състояние на стоп.
%MLMTD – колко дълго през периода на измерване vCPU е бил в състояние Ready поради зададения лимит на ресурса.
%WAIT + %RDY + %CSTP + %RUN = 100% - VM ядрото винаги е в едно от тези четири състояния.
Процесор на хипервайзор
vCenter също има броячи на производителността на процесора за хипервайзора, но те не са нищо интересно - това е просто сумата от броячите за всички VM на сървъра.
Най-удобният начин да видите състоянието на процесора на сървъра е в раздела Резюме:
За сървъра, както и за виртуалната машина, има стандартна аларма:
Когато натоварването на процесора на сървъра е високо, работещите на него виртуални машини започват да изпитват проблеми с производителността.
В ESXTOP данните за натоварването на процесора на сървъра се представят в горната част на екрана. В допълнение към стандартното натоварване на процесора, което не е много информативно за хипервайзорите, има още три показателя:
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 USE за двете нишки ще бъде 50%.
Ако и двете нишки не са работили 100% от времето по време на периода на измерване, тогава през тези периоди, когато нишките са работили паралелно, PCPU, ИЗПОЛЗВАН за ядрата, е наполовина.
ESXTOP също има екран с опции за захранване на сървърния процесор. Тук можете да видите дали сървърът използва енергоспестяващи технологии: C-states и P-states. Извиква се с клавиша "p":
Често срещани проблеми с производителността на процесора
И накрая, ще разгледам типичните причини за проблеми с производителността на VM CPU и ще дам кратки съвети за разрешаването им:
Недостатъчен часовник на ядрото. Ако не е възможно да надстроите VM до по-мощни ядра, можете да опитате да промените настройките на мощността, така че Turbo Boost да работи по-ефективно.
Грешно оразмеряване на VM (твърде много/малко ядра). Ако поставите малко ядра, ще има голямо натоварване на процесора на VM. Ако е много, хванете висок ко-стоп.
Голямо претоварване на процесора на сървъра. Ако виртуалната машина е във висока степен на готовност, намалете претоварването на процесора.
Грешна NUMA топология на големи виртуални машини. Топологията NUMA, виждана от VM (vNUMA), трябва да съответства на топологията NUMA на сървъра (pNUMA). За диагнозата и възможните решения на този проблем е написано например в книгата . Ако не искате да се задълбочавате и нямате лицензионни ограничения за операционната система, инсталирана на VM, направете много виртуални сокети на VM за едно ядро. Няма да загубите много 🙂
Това е всичко за процесора за мен. Задавайте въпроси. В следващата част ще говоря за RAM.
Полезни връзки
Източник: www.habr.com