Ако администрирате виртуална инфраструктура на базата на VMware vSphere (или друга технология), вероятно често чувате от потребителите оплаквания: «Виртуалната машина работи бавно!». В този цикъл от статии ще разгледам метриките за производителност и ще обясня как и защо „забавя“ и как да постигнем оптимизирана работа без забавяне.
Ще разглеждам следните аспекти на производителността на виртуалните машини:
- CPU,
- RAM,
- DISK,
- Мрежа.
Започвам с CPU.
За анализа на производителността ще ни трябват:
- vCenter Performance Counters – счетчици на производителността, чийто графики могат да бъдат прегледани чрез vSphere Client. Информацията за тези счетчици е достъпна във всяка версия на клиента (толкова) клиент на C#, уеб клиент на Flex и уеб клиент на HTML5). В тези статии ще използваме скрийншотове от C# клиента, само защото те изглеждат по-добре в миниатюра:)
- ESXTOP – инструмент, който може да бъде стартиран от командния ред на ESXi. С него можете да получите стойности на счетчици на производителността в реално време или да експортирате тези стойности за определен период в .csv файл за по-нататъшен анализ. По-късно ще говоря по-подробно за този инструмент и ще предоставя няколко полезни линка към документация и статии по темата.
Няколко теории
В ESXi за работата на всеки vCPU (ядро на виртуалната машина) отговаря отделен процес – world в терминологията на VMware. Съществуват и служебни процеси, но от гледна точка на анализа на производителността на ВМ те са по-малко интересни.
Процесът в ESXi може да бъде в едно от четирите състояния:
- Стартиране – процесът изпълнява полезна работа.
- Изчакване – процесът не извършва никаква работа (idle) или чака вход/изход.
- Costop – състояние, което възниква в многоядрени виртуални машини. То се появява, когато планировчикът на CPU на хипервизора (ESXi CPU Scheduler) не може да планира едновременното изпълнение на физическите ядра на сървъра за всички активни ядра на виртуалната машина. В физическия свят всички ядра на процесора работят паралелно, а гостуващата ОС в рамките на ВМ разчита на подобно поведение, затова хипервизорът е принуден да забавя ядрата на ВМ, които имат възможност да завършат такта по-бързо. В съвременните версии на ESXi планировчикът на CPU използва механизъм, наречен relaxed co-scheduling: хипервизорът отчита разликата между най-бързото и най-бавното ядро на виртуалната машина (skew). Ако разликата надвишава определен праг, бързото ядро преминава в състояние costop. Ако ядрата на ВМ прекарват много време в това състояние, това може да предизвика проблеми с производителността.
- Готов – процес преминава в това състояние, когато хипервизорът няма възможност да разпредели ресурси за неговото изпълнение. Високите стойности на ready могат да предизвикат проблеми с производителността на ВМ.
Основни счетчици за производителността на CPU на виртуалната машина
Използване на CPU, %. Показва процента на използване на CPU за зададен период.
Как да анализираме? Ако ВМ стабилно използва CPU на 90% или има пикове до 100%, то срещаме проблеми. Проблемите могат да се проявят не само в бавната работа на приложението вътре в ВМ, но и в недостъпността на ВМ по мрежата. Ако системата за мониторинг показва, че ВМ периодично изпада, обърнете внимание на пиковете в графика на Използването на CPU.
Има стандартен аларм, който показва натоварването на CPU на виртуалната машина:
Какво да правим? Ако на ВМ постоянно е високо Използването на CPU, може да се помисли за увеличаване на броя на vCPU (за съжаление, това не винаги помага) или преместване на ВМ на сървър с по-производителни процесори.
Използване на CPU в MHz
В графиките на vCenter Използване в % може да се види само за цялата виртуална машина, графици по отделни ядра няма (в Esxtop стойностите в % по ядра съществуват). За всяко ядро може да се види Използването в MHz.
Как да анализираме? Има случаи, когато приложението не е оптимизирано за многоядрена архитектура: използва на 100% само едно ядро, а останалите остават без натоварване. Например, при стандартни настройки на резервно копие MS SQL стартира процес само на едно ядро. В резултат на това резервното копиране забавя не поради бавната скорост на дисковете (на което първоначално се оплака потребителят), а защото процесорът не справя. Проблемът беше решен с промяна на параметрите: резервното копиране започна да се извършва паралелно в няколко файла (съответно, в няколко процеса).
Пример за неравномерно натоварване на ядрата.
Също така, често се случва (както е показано на графиката по-горе), когато ядрата са натоварени неравномерно и на някои от тях има пикове до 100%. Както и при натоварване само на едно ядро, алармата по CPU Usage няма да сработи (тя е за цялата ВМ), но проблеми с производителността ще настъпят.
Какво да правим? Ако софтуерът в виртуалната машина натоварва ядрата неравномерно (използва само едно ядро или част от ядрата), няма смисъл да се увеличава техният брой. В такъв случай по-добре е да се премести ВМ на сървър с по-производителни процесори.
Също така можете да опитате да проверите настройките за енергийна консумация в BIOS на сървъра. Много администратори активират в BIOS режим High Performance, с което изключват технологии за пестене на енергия, като C-states и P-states. В съвременните процесори Intel се използва технология Turbo Boost, която увеличава честотата на отделни ядра на процесора за сметка на другите ядра. Но тя работи само при включени технологии за пестене на енергия. Ако ги изключим, процесорът не може да намали енергопотреблението на ядрата, които не са натоварени.
VMware препоръчва да не се изключват технологии за пестене на енергия на сървърите, а да се избират режимите, които максимално предоставят управлението на енергопотреблението на хипервизора. При това в настройките за енергийна консумация на хипервизора трябва да се избере High Performance.
Ако имате отделни ВМ (или ядра на ВМ), които изискват повишена честота на CPU, правилната настройка на енергопотреблението може значително да подобри тяхната производителност.
CPU Ready (Готовност)
Ако VM ядрото (vCPU) е в състояние Ready, то не извършва полезна работа. Такова състояние възниква, когато хипервизорът не може да намери свободно физическо ядро, на което да зададе процес vCPU на виртуалната машина.
Как да анализираме? Обикновено, ако ядрата на виртуалната машина са в състояние Ready повече от 10% от времето, ще забележите проблеми с производителността. По-просто казано, повече от 10% от времето VM очаква наличността на физически ресурси.
В vCenter можете да видите 2 метрики, свързани с CPU Ready:
- Readiness,
- Ready.
Стойностите на двете метрики могат да се видят както за цялата VM, така и за отделните ядра.
Readiness показва стойността в проценти, но само в Real-time (данни за последния час, измервания на интервали от 20 секунди). Тази метрика е по-добре да се използва само за откриване на проблеми „на място“.
Стойностите на метриката Ready също могат да се видят в историческа перспектива. Това е полезно за установяване на закономерности и за по-дълбочинен анализ на проблема. Например, ако виртуалната машина започне да има проблеми с производителността в определено време, можете да сопоставите периодите на повишена стойност на CPU Ready с общото натоварване на сървъра, на който работи тази VM, и да предприемете мерки за намаляване на натоварването (ако DRS не се е справил).
Ready, за разлика от Readiness, се показва не в проценти, а в милисекунди. Тази метрика е от тип Summation, тоест показва колко време по време на измерванията ядрото на VM е било в състояние Ready. Можете да преобразувате тази стойност в проценти по следната формула:
(CPU ready summation value / (chart default update interval in seconds * 1000)) * 100 = CPU ready %
Например, за VM на графиката по-долу, пикова стойност Ready за цялата виртуална машина ще бъде следната:
При изчисляване на стойността Ready в проценти, трябва да се обърне внимание на два аспекта:
- Стойността Ready за цялата VM е сумата на Ready по ядрата.
- Интервалът на измерване. За Real-time – това е 20 секунди, а например, за дневни графики – 300 секунди.
При активно решаване на проблеми, тези прости моменти могат лесно да бъдат пренебрегнати и можете да загубите ценно време за решаване на не съществуващи проблеми.
Нека изчислим Ready на базата на данните от графика по-долу. (324474/(20*1000))*100 = 1622% за цялата ВМ. Ако погледнем по ядра, вече не изглежда толкова страшно: 1622/64 = 25% на ядро. В този случай е доста лесно да се забележи подвохът: стойността на Ready е нереалистична. Но ако става въпрос за 10–20% за цялата ВМ с няколко ядра, тогава стойността за всяко ядро може да е в пределите на нормата.
Какво да правим? Високото значение на Ready означава, че на сървъра му липсват ресурси от процесора за нормална работа на виртуалните машини. В такава ситуация остава само да се намали надписването на процесора (vCPU:pCPU). Очевидно, това може да се постигне, като се намалят параметрите на съществуващите ВМ или чрез миграция на част от ВМ на други сървъри.
Co-stop
Как да анализираме? Този брояч също има тип Summation и се преобразува в проценти, аналогично на Ready:
(CPU co-stop summation value / (chart default update interval in seconds * 1000)) * 100 = CPU co-stop %
Тук също трябва да се обърне внимание на броя на ядрата на ВМ и на интервала на измерване.
В състояние co-stop ядро не изпълнява полезна работа. При правилен подбор на размера на ВМ и нормално натоварване на сървъра, броячът co-stop трябва да бъде близо до нула.
В този случай натоварването явно не е нормално :)
Какво да правим? Ако на един хипервизор работят няколко ВМ с голям брой ядра и има надписване на CPU, тогава броячът co-stop може да нарасне, което да доведе до проблеми с производителността на тези ВМ.
Също така co-stop ще нарасне, ако за активните ядра на една ВМ се използват нишки на едно физическо ядро на сървера, с включен hyper-threading. Такава ситуация може да възникне, например, ако ВМ има повече ядра, отколкото физически има на сървера, на който работи, или ако за ВМ е включена настройката “preferHT”. За тази настройка може да се прочете .
За да избегнете проблеми с производителността на ВМ поради висок co-stop, избирайте размера на ВМ в съответствие с препоръките на производителя на софтуера, който работи на тази ВМ, и възможностите на физическия сървър, на който работи ВМ.
Не добавяйте ядра за всеки случай, това може да предизвика проблеми с производителността не само на самата ВМ, но и на нейните съседи на сървера.
Други полезни метрики на CPU
Стартиране – колко време (мс) по време на измервателния период vCPU е бил в състояние RUN, т.е. всъщност е изпълнявал полезна работа.
Idle – колко време (мс) по време на измерването vCPU е бил в състояние на бездействие. Високите стойности на Idle не са проблем, просто vCPU не е имал какво да прави.
Изчакване – колко време (мс) по време на измерването vCPU е бил в състояние на Wait. Тъй като в този брояч се включва IDLE, високите стойности на Wait също не говорят за наличие на проблем. Но ако при висок Wait IDLE е нисък, значи ВМ е чакала приключването на операции с вход/изход, което може да сигнализира за проблеми с производителността на твърдия диск или на виртуалните устройства на ВМ.
Max limited – колко време (мс) по време на измерването 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 от това, че не взема предвид хипернишките потоци, мащабирането на честотата и времето, прекарано за системни задачи (%SYS).
%SYS – времето, прекарано за системни задачи, например: обработка на прекъсвания, вход/изход, работа в мрежата и др. Стойността може да бъде висока, ако ВМ генерира голямо количество вход/изход.
%OVRLP – колко време физическото ядро, на което се изпълнява процесът ВМ, е прекарало в задачи на други процеси.
Тези метрики са свързани помежду си по следния начин:
%USED = %RUN + %SYS — %OVRLP.
Обикновено метриката %USED е по-информативна.
%WAIT – колко време по време на измерването процесът е бил в състояние Wait. Включва IDLE.
%IDLE – колко време по време на измерването процесът е бил в състояние IDLE.
%SWPWT – колко време по време на измерването vCPU е чакал операция с VMkernel Swap.
%VMWAIT – колко време по време на измерването vCPU е било в състояние на изчакване на събитие (обикновено вход/изход). Не съществува аналогичен брояч в vCenter. Високите стойности показват проблеми с вход/изхода на ВМ.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Ако ВМ не използва VMkernel Swap, при анализ на проблеми с производителността е целесъобразно да се наблюдава %VMWAIT, тъй като тази метрика не взема предвид времето, когато ВМ не е правила нищо (%IDLE).
%RDY – колко време по време на измерването процесът е бил в състояние Ready.
%CSTP – колко време по време на измерването процесът е бил в състояние costop.
%MLMTD – колко време по време на измерването vCPU е било в състояние Ready поради наложен лимит на ресурсите.
%WAIT + %RDY + %CSTP + %RUN = 100% – ядрото на ВМ винаги е в някое от тези четири състояния.
CPU на хипервизора
В vCenter има и счетчици за производителността на CPU за хипервизора, но те не представляват нищо особено – просто сбор от броячи за всички ВМ на сървера.
Най-удобно е да се наблюдава състоянието на CPU на сървера на таба Summary:
За сървера, както и за виртуалната машина, съществува стандартен Alarm:
При висока натовареност на CPU на сървера, ВМ, работещи на него, започват да имат проблеми с производителността.
В ESXTOP данните за натоварването на CPU на сървъра са представени в горната част на екрана. Освен стандартното натоварване на CPU, което е малко информативно за хипервизорите, има още три метрики:
CORE UTIL(%) – натоварването на ядрото на физическия сървър. Този показател показва колко време в периода на измерване ядрото е изпълнявало работа.
PCPU UTIL(%) – ако е включен хипер-нишковането, на всяко физическо ядро се падат два потока (PCPU). Тази метрика показва колко време всеки поток е изпълнявал работа.
PCPU USED(%) – същото като PCPU UTIL(%), но взема предвид и scaling на честотата (или намаляване на честотата на ядрото с цел пестене на енергия, или повишаване на честотата на ядрото чрез технологията Turbo Boost) и хипер-нишковане.
PCPU_USED% = PCPU_UTIL% * ефективната честота на ядрото / номиналната честота на ядрото.
На този скрийншот за някои ядра, поради работата на Turbo Boost, стойността USED е над 100%, тъй като честотата на ядрото е по-висока от номиналната.
Няколко думи за това как се взима предвид хипер-нишковането. Ако процесите работят 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 на сървера. Ако на ВМ има високо Ready, намалете пренатрупаността на CPU.
Неправилна NUMA топология на големи ВМ. NUMA топологията, която вижда ВМ (vNUMA), трябва да съответства на NUMA топологията на сървъра (pNUMA). За диагностика и възможни решения на този проблем е писано, например, в книгата . Ако не искате да се задълбочавате и нямате лицензионни ограничения върху ОС, инсталирана на ВМ, направете много виртуални сокети по едно ядро на ВМ. Много няма да загубите 🙂
С това за CPU при мен приключих. Задавайте въпроси. В следващата част ще разкажа за оперативната памет.
Полезни линкове
Източник: habr.com
