Ако администрирате виртуална инфраструктура, базирана на VMware vSphere (или друга технологична стек), вероятно често чувате от потребителите оплаквания: „Виртуалната машина работи бавно!“. В този цикъл статии ще разгледам метриките за производителност и ще обясня какво и защо „задържа“ и как да направим така, че да не „задържа“.
Ще разгледам следните аспекти на производителността на виртуалните машини:
- CPU,
- RAM,
- DISK,
- Network.
Ще започна с CPU.
За анализа на производителността ще ни трябват:
- vCenter Performance Counters – счетчици за производителност, чиито графики могат да се видят през vSphere Client. Информация за тези счетчици е налична във всяка версия на клиента (“дебел” клиент на C#, уеб-клиент на Flex и уеб-клиент на HTML5). В тези статии ще използваме скрийншотове от C# клиента, просто защото те изглеждат по-добре в миниатюра:)
- ESXTOP – инструмент, който се стартира от командния ред на ESXi. С него можете да получите стойности на счетчиците за производителност в реално време или да експортирате тези стойности за определен период в .csv файл за по-нататъшен анализ. По-късно ще разкажа повече за този инструмент и ще предоставя няколко полезни връзки към документация и статии по темата.
Няколко теории
В ESXi за работата на всеки vCPU (ядро на виртуалната машина) отговаря отделен процес – world в терминологията на VMware. Съществуват също служебни процеси, но от гледна точка на анализа на производителността на ВМ те са по-малко интересни.
Процесът в ESXi може да бъде в едно от четирите състояния:
- Run – процесът извършва някаква полезна работа.
- Wait – процесът не извършва никаква работа (неактивен) или изчаква входно/изходни операции.
- Costop – състояние, което възниква в многоядрените виртуални машини. То се появява, когато планировчикът на CPU на хипервизора (ESXi CPU Scheduler) не може да запланува simultanно изпълнение на физическите ядра на сървъра със всички активни ядра на виртуалната машина. В физическия свят всички ядра на процесора работят паралелно, хостващата ОС вътре в ВМ разчита на аналогично поведение, поради което хипервизорът е принуден да забавя ядрата на ВМ, които имат възможност да завършат такта по-бързо. В съвременните версии на ESXi планировчикът на CPU използва механизъм, наречен relaxed co-scheduling: хипервизорът изчислява разликата между най-"бързото" и най-"бавното" ядро на виртуалната машина (skew). Ако разликата надвишава определен праг, "бързото" ядро преминава в състояние costop. Ако ядрата на ВМ прекарват много време в това състояние, това може да причини проблеми с производителността.
- Готово – процесът преминава в това състояние, когато хипервизорът няма възможност да разпредели ресурси за неговото изпълнение. Високите стойности ready могат да причинят проблеми с производителността на ВМ.
Основни метрики за производителност на CPU на виртуалната машина
Използване на CPU, % Показва процента на използване на CPU за определен период.
Как да анализираме? Ако ВМ стабилно използва CPU на 90% или има пикове до 100%, то ние имаме проблеми. Проблемите могат да се изразяват не само в "бавната" работа на приложението вътре в ВМ, но и в недостъпността на ВМ по мрежата. Ако системата за мониторинг показва, че ВМ периодично губи свързаност, обърнете внимание на пиковете в графиката за Използване на CPU.
Има стандартен Аlarm, който показва натоварването на CPU на виртуалната машина:
Какво да правим? Ако натоварването на CPU на ВМ постоянно е над допустимите стойности, можете да помислите за увеличаване на броя на vCPU (за съжаление, това не винаги помага) или преместване на ВМ на сървър с по-производителни процесори.
Използване на CPU в MHz
В графиките на vCenter Използване в % може да се види само за цялата виртуална машина, графики по отделни ядра няма (в Esxtop стойностите в % по ядра са налични). По всяко ядро можетe да видите Използване в MHz.
Как да анализираме? Понякога приложението не е оптимизирано за многоядрена архитектура: използва на 100% само едно ядро, а останалите остават без натоварване. Например, при стандартни настройки на резервното копие MS SQL стартира процес само на едно ядро. В крайна сметка резервното копиране забавя не заради бавната скорост на дисковете (точно за това първоначално се оплака потребителят), а защото процесорът не се справя. Проблемът беше решен с промени в параметрите: резервното копиране започна да се изпълнява паралелно в няколко файла (съответно, в няколко процеса).
Пример за неравномерно натоварване на ядрата.
Съществува и ситуация (както на графиката по-горе), когато ядрата са натоварени неравномерно и на някои от тях има върхове на натоварване от 100%. Както и при натоварване само на едно ядро, алармата по CPU Usage не сработва (тя важи за цялата ВМ), но проблеми с производителността ще се проявят.
Какво да правим? Ако софтуерът във виртуалната машина натоварва ядрата неравномерно (използва само едно ядро или част от ядрата), няма смисъл да увеличавате техния брой. В такъв случай е по-добре да преместите ВМ на сървър с по-производителни процесори.
Също така можете да опитате да проверите настройките за енергопотребление в BIOS на сървъра. Много администратори активират режима High Performance в BIOS, което деактивира технологиите за спестяване на енергия C-states и P-states. В съвременните процесори Intel се използва технологията Turbo Boost, която увеличава честотата на отделни ядра на процесора за сметка на другите ядра. Но тя работи само когато технологиите за спестяване на енергия са включени. Ако ги изключим, процесорът не може да намали енергопотреблението на ядрата, които не са натоварени.
VMware препоръчва да не се деактивират технологиите за спестяване на енергия на сървърите, а да се избират режими, които максимално предоставят управлението на енергопотреблението на хипервизора. При това в настройките за енергопотребление на хипервизора трябва да изберете High Performance.
Ако в инфраструктурата ви отделни ВМ (или ядра на ВМ) изискват повишена честота на CPU, коректната настройка на енергопотреблението може значително да подобри тяхната производителност.
CPU Ready (Готовност)
Ако ядрото на ВМ (vCPU) е в състояние Ready, то не извършва полезна работа. Това състояние възниква, когато хипервизорът не намери свободно физическо ядро, на което да назначи процес vCPU на виртуалната машина.
Как да анализираме? Обикновено, ако ядрата на виртуалната машина са в състояние Ready повече от 10% от времето, ще забележите проблеми с производителността. С други думи, повече от 10% от времето ВМ изчаква наличността на физически ресурси.
В vCenter можете да видите 2 брояча, свързани с CPU Ready:
- Readiness,
- Ready.
Стойностите на двата брояча можете да видите както за цялата ВМ, така и за отделните ядра.
Readiness показва стойността веднага в проценти, но само в реално време (данни за последния час, интервал на измерванията 20 секунди). Този брояч е по-добре да се използва само за откриване на проблеми "в движение".
Стойностите на брояча Ready могат да се видят и в историческа перспектива. Това е полезно за установяване на закономерности и за по-дълбок анализ на проблема. Например, ако виртуалната машина има проблеми с производителността в определено време, можете да съпоставите интервалите с повишена стойност на CPU Ready с общото натоварване на сървъра, на който работи ВМ, и да предприемете мерки за намаляване на натоварването (ако DRS не е справил).
Ready, за разлика от Readiness, се показва не в проценти, а в милисекунди. Това е брояч от тип Summation, т.е. той показва колко време в период на измерване ядрото на ВМ е било в състояние Ready. Тази стойност можете да преобразувате в проценти по несложна формула:
(стойност на summation на CPU ready / (стандартен интервал за актуализиране на графиката в секунди * 1000)) * 100 = CPU ready %
Например, за ВМ на графиката по-долу, пикова стойност на Ready за цялата виртуална машина ще бъде следната:
При изчисляване на стойността на Ready в проценти, е важно да се обърне внимание на два момента:
- Стойността на Ready за цялата ВМ – това е сумата на Ready по ядрата.
- Интервал на измерване. За реално време – това е 20 секунди, а например на дневните графики – 300 секунди.
При активен траблшутинг, тези прости моменти могат лесно да бъдат пропуснати и да се загуби ценно време за решаване на несъществуващи проблеми.
Ще изчислим Ready на базата на данните от графика по-долу. (324474/(20*1000))*100 = 1622% за цялата VM. Ако погледнем по ядра, ситуацията не изглежда толкова зле: 1622/64 = 25% на ядро. В този случай е доста лесно да се открие капанът: стойността Ready е нереалистична. Но ако става въпрос за 10–20% за цялата VM с няколко ядра, тогава стойността за всяко ядро може да бъде в пределите на нормалното.
Какво да правим? Високата стойност на Ready показва, че на сървъра не му достигат процесорни ресурси за нормалната работа на виртуалните машини. В такава ситуация остава само да се намали преоптимизацията на процесора (vCPU:pCPU). Очевидно, това може да се постигне, като се намалят параметрите на съществуващите VM или чрез мигриране на част от VM на други сървъри.
Co-stop
Как да анализираме? Този брояч също има тип Summation и се преизчислява в проценти по аналогия с Ready:
(CPU co-stop summation value / (период на актуализация по подразбиране на графика в секунди * 1000)) * 100 = CPU co-stop %
Тук също е необходимо да се обърне внимание на броя на ядрата на VM и на интервала на измерване.
В състояние co-stop ядро не извършва полезна работа. При правилен избор на размера на VM и нормално натоварване на сървъра, броячът co-stop трябва да бъде близо до нула.
В този случай натоварването явно е ненормално :)
Какво да правим? Ако на един хипервизор работят няколко VM с много ядра и има преоптимизация на CPU, броячът co-stop може да нарасне, което ще доведе до проблеми с производителността на тези VM.
Също така, co-stop ще нарасне, ако за активните ядра на една VM се използват нишки на едно физическо ядро на сървера с включен hyper-threading. Такава ситуация може да възникне, например, ако VM има повече ядра, отколкото физически са налични на сървера, на който работи, или ако за VM е включена настройката "preferHT". За тази настройка можете да прочетете .
За да избегнете проблеми с производителността на VM поради висок co-stop, изберете размера на VM в съответствие с препоръките на производителя на софтуера, който работи на тази VM, и с възможностите на физическия сървър, на който работи VM.
Не добавяйте ядра про запас, това може да доведе до проблеми с производителността не само на самата VM, но и на нейните съседи на сървера.
Други полезни метрики на CPU
Run – колко време (мс) по време на измервателния период vCPU е бил в състояние RUN, т.е. всъщност е извършвал полезна работа.
Idle – колко време (мс) по време на измерването vCPU е бил в състояние на бездействие. Високите стойности Idle не са проблем, просто vCPU е нямал „какво да прави“.
Wait – колко време (мс) по време на измерването vCPU е бил в състояние Wait. Тъй като в този брояч се включва IDLE, високите стойности Wait също не говорят за наличие на проблем. Но ако при висок Wait IDLE е нисък, това означава, че ВМ е изчаквала завършването на операции за вход/изход, а това от своя страна може да показва проблем с производителността на твърдия диск или някакви виртуални устройства на ВМ.
Максимално ограничение – колко време (мс) по време на измерването vCPU е бил в състояние Ready заради установен лимит на ресурсите. Ако производителността е необяснимо ниска, полезно е да проверите стойността на този брояч и лимита на CPU в настройките на ВМ. Възможно е ВМ наистина да има зададени лимити, за които не знаете. Например, това се случва, когато ВМ е клонирана от шаблон, върху който е имало установен лимит на CPU.
Swap wait – колко време по време на измерването vCPU е изчаквал операции с VMkernel Swap. Ако стойностите на този брояч са над нула, значи ВМ определено има проблеми с производителността. По-подробно за SWAP ще говорим в статията за броячите на оперативната памет.
ESXTOP
Ако броячите за производителност в vCenter са добри за анализ на исторически данни, то оперативният анализ на проблема е по-добре да се извършва в ESXTOP. Тук всички стойности са представени в готов вид (не е нужно нищо да се превежда), а минималният период на измерване е 2 секунди.
Екранът ESXTOP по CPU се извиква с клавиша „c“ и изглежда по следния начин:
За удобство можете да оставите само процесите на виртуалните машини, като натиснете Shift-V.
За да видите метриките по отделни ядра на ВМ, натиснете „e“ и въведете GID на интересуващата ВМ (30919 на екрана по-долу):
Накратко ще премина през колоните, които са представени по подразбиране. Допълнителни колони можете да добавите, натискайки „f“.
NWLD (Брой светове) – брой процеси в групата. За да разширите групата и да видите метрики за всеки процес (например, за всяко ядро на многоядрена ВМ), натиснете “e”. Ако в групата има повече от един процес, то стойностите на метриките за групата са равни на сумата на метриките за отделните процеси.
%USED – колко цикъла на CPU сервера използва процеса или групата процеси.
%RUN – колко време по време на измервателния период процесът е бил в състояние RUN, т.е. е извършвал полезна работа. Различава се от %USED поради факта, че не отчита hyper-threading, frequency scaling и времето, прекарано за системни задачи (%SYS).
%SYS – времето, което е прекарано за системни задачи, например: обработка на прекъсвания, вход/изход, работа в мрежа и др. Стойността може да бъде висока, ако VM има голям вход/изход.
%OVRLP – колко време физическото ядро, на което се изпълнява процесът на VM, е прекарало на задачи на други процеси.
Тези метрики се отнасят помежду си по следния начин:
%USED = %RUN + %SYS — %OVRLP.
Обикновено метриката %USED е по-информативна.
%WAIT – колко време по време на измервателния период процесът е бил в състояние Wait. Включва IDLE.
%IDLE – колко време по време на измервателния период процесът е бил в състояние IDLE.
%SWPWT – колко време по време на измервателния период vCPU е чакал операция с VMkernel Swap.
%VMWAIT – колко време по време на измервателния период vCPU е било в състояние на очакване на събитие (обикновено вход/изход). Няма аналогичен брояч в vCenter. Високите стойности говорят за проблеми с вход/изход на VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Ако VM не използва VMkernel Swap, то при анализа на проблеми с производителността е разумно да се гледа на %VMWAIT, тъй като тази метрика не отчита времето, когато VM не е правела нищо (%IDLE).
%RDY – колко време по време на измервателния период процесът е бил в състояние Ready.
%CSTP – колко време по време на измервателния период процесът е бил в състояние costop.
%MLMTD – колко време по време на измервателния период vCPU е било в състояние Ready поради зададен лимит на ресурсите.
%WAIT + %RDY + %CSTP + %RUN = 100% – ядрото на VM винаги е в някое от тези четири състояния.
CPU на хипервизора
В vCenter също има броячи за производителността на CPU за хипервизора, но те не представляват нищо интересно – това е просто сума от броячите на всички VM на сървъра.
Най-удобно е да се наблюдава състоянието на CPU на сървъра на таба Summary:
За сървъра, както и за виртуалната машина, има стандартен Alarm:
При висока натовареност на CPU на сървъра, VM, работещи на него, започват да имат проблеми с производителността.
В ESXTOP информация за натоварването на CPU на сървъра е представена в горната част на екрана. Освен стандартното натоварване на CPU, което е малко информативно за хипервизорите, има още три метрики:
CORE UTIL(%) – натоварване на ядрото на физическия сървър. Тази метрика показва колко време през измервателния период ядрото е извършвало работа.
PCPU UTIL(%) – ако е активиран hyper-threading, на всяко физическо ядро се падат два потока (PCPU). Тази метрика показва колко време всеки поток е извършвал работа.
PCPU USED(%) – същото като PCPU UTIL(%), но отчита frequency scaling (или намаляване на честотата на ядрото с цел пестене на енергия, или увеличаване на честотата на ядрото благодарение на технологията Turbo Boost) и hyper-threading.
PCPU_USED% = PCPU_UTIL% * ефективната честота на ядрото / номиналната честота на ядрото.
На този екран за някои ядра поради работата на Turbo Boost значението USED е над 100%, тъй като честотата на ядрото е по-висока от номиналната.
Нямам нищо против да споделя малко за това как се отчита hyper-threading. Ако процесите работят 100% от времето на двата потока на физическото ядро на сървъра, при това ядрото работи на номиналната си честота, то:
- CORE UTIL за ядрото ще бъде 100%,
- PCPU UTIL за двата потока ще бъде 100%,
- PCPU USED за двата потока ще бъде 50%.
Ако и двата потока не работиха 100% от времето в измервателния период, тогава в периодите, когато потоките работят паралелно, PCPU USED за ядрата се дели на две.
В ESXTOP има и екран с параметрите за енергийно потребление на CPU на сървъра. Тук можете да видите дали сървърът използва технологии за спестяване на енергия: C-states и P-states. Активира се с клавиша «p»:
Стандартни проблеми с производителността на CPU
Накрая, бих искал да спомена типичните причини за проблеми с производителността на CPU на ВМ и да дам кратки съвети за тяхното решение:
Липсва тактова честота на ядрото. Ако няма възможност да се премести ВМ на по-производителни ядра, можете да опитате да промените настройките за енергийна ефективност, за да работи Turbo Boost по-ефективно.
Неправилно оразмеряване на ВМ (прекалено много/малко ядра). Ако поставите твърде малко ядра, ще имате високо натоварване на CPU на ВМ. Ако поставите твърде много, ще получите висок co-stop.
Висока пренасищане на CPU на сървъра. Ако ВМ има високо време на готовност, намалете пренасищането на CPU.
Неправилна NUMA-топология на големите ВМ. NUMA топологията, която ВМ (vNUMA) вижда, трябва да съответства на NUMA топологията на сървъра (pNUMA). За диагностицирането и възможните варианти за решаване на този проблем е написано, например, в книгата . Ако не искате да се задълбочавате и нямате лицензионни ограничения по ОС, инсталирана на ВМ, направете на ВМ много виртуални сокети с по одно ядро. Няма да загубите много 🙂
С това по CPU приключвам. Задавайте въпроси. В следващата част ще разкажа за оперативната памет.
Полезни връзки
Източник: habr.com
