Якщо ви адмініструєте віртуальну інфраструктуру на базі VMware vSphere (або будь-якого іншого стеку технологій), то, напевно, часто чуєте від користувачів скарги: «Віртуальна машина працює повільно!». У цьому циклі статей розберу метрики продуктивності та розповім, що і чому «гальмує» і як зробити так, щоб не «гальмувало».
Розглядатиму наступні аспекти продуктивності віртуальних машин:
- CPU,
- ОЗП,
- DISK,
- Мережа
Почну із CPU.
Для аналізу продуктивності нам знадобляться:
- vCenter Performance Counters – лічильники продуктивності, графіки яких можна переглянути через vSphere Client. Інформація за даними лічильникам доступна у будь-якій версії клієнта (“товстий” клієнт на C#, web-клієнт на Flex та web-клієнт на HTML5). У даних статтях ми використовуватимемо скріншоти з С#-клієнта, тільки тому, що вони краще виглядають у мініатюрі:)
- ESXTOP - Утиліта, яка запускається з командного рядка ESXi. З її допомогою можна отримати значення лічильників продуктивності в реальному часі або вивантажити ці значення за певний період у файл .csv для подальшого аналізу. Далі розповім про цей інструмент докладніше та наведу кілька корисних посилань на документацію та статті на тему.
Трохи теорії
В ESXi за роботу кожного vCPU (ядра віртуальної машини) відповідає окремий процес – world у термінології VMware. Також є службові процеси, але з погляду аналізу продуктивності ВМ вони менш цікаві.
Процес ESXi може знаходитися в одному з чотирьох станів:
- прогін - Процес виконує якусь корисну роботу.
- Почекай – процес не виконує ніякої роботи (idle) або чекає на введення/виведення.
- Costop – стан, що виникає у багатоядерних віртуальних машинах. Воно виникає, коли планувальник CPU гіпервізора (ESXi CPU Scheduler) не може запланувати одночасне виконання фізичних ядрах сервера всіх активних ядер віртуальної машини. У фізичному світі всі ядра процесора працюють паралельно, гостьова ОС всередині ВМ розраховує на аналогічну поведінку, тому гіпервізору доводиться уповільнювати ядра ВМ, які мають можливість закінчити такт швидше. У сучасних версіях ESXi планувальник CPU використовує механізм, який називається relaxed co-scheduling: гіпервізор вважає розрив між «найшвидшим» і «найповільнішим» ядром віртуальної машини (skew). Якщо розрив перевищує певний поріг, «швидке» ядро перетворюється на стан costop. Якщо ядра ВМ проводять багато часу в цьому стані, це може спричинити проблеми з продуктивністю.
- Готовий – процес переходить у цей стан, коли гіпервізор не має можливості виділити ресурси для його виконання. Високі значення ready можуть спричинити проблеми з продуктивністю ВМ.
Основні лічильники продуктивності CPU віртуальної машини
CPU Usage, %. Показує процент використання CPU за заданий період.
Як аналізувати? Якщо ВМ стабільно використовує CPU на 90% або є пік до 100%, то у нас проблеми. Проблеми можуть виражатися у «повільної» роботі програми всередині ВМ, а й у недоступності ВМ через мережу. Якщо система моніторингу показує, що ВМ періодично відвалюється, зверніть увагу на піки графіки CPU Usage.
Є стандартний Аlarm, який показує завантаження CPU віртуальної машини:
Що робити? Якщо у ВМ постійно зашкалює CPU Usage, то можна задуматися про збільшення кількості vCPU (на жаль, це не завжди допомагає) або перенесення ВМ на сервер з більш продуктивними процесорами.
CPU Usage in Mhz
У графіках на vCenter Usage у % можна подивитися тільки по всій віртуальній машині, графіків по окремих ядрах немає (в Esxtop значення % по ядрах є). По кожному ядру можна переглянути Usage in MHz.
Як аналізувати? Буває, що програма не оптимізована під багатоядерну архітектуру: використовує на 100% лише одне ядро, а інші простоюють без навантаження. Наприклад, при дефолтних налаштуваннях бекапу MS SQL запускає процес лише одному ядрі. В результаті резервне копіювання гальмує не через повільну швидкість дисків (саме на це спочатку поскаржився користувач), а через те, що не справляється процесор. Проблема була вирішена зміною параметрів: резервне копіювання стало запускатися паралельно кілька файлів (відповідно, кілька процесів).
Приклад нерівномірного навантаження ядер.
Також буває ситуація (як на графіці вище), коли ядра навантажені нерівномірно і на деяких з них є піки 100%. Як і при завантаженні лише одного ядра, alarm по CPU Usage не спрацює (він по всій ВМ), але проблеми з продуктивністю будуть.
Що робити? Якщо програмне забезпечення у віртуальній машині навантажує ядра нерівномірно (використовує лише одне ядро чи частину ядер), немає сенсу збільшувати їх кількість. У такому разі краще перемістити ВМ на сервер із більш продуктивними процесорами.
Також можна спробувати перевірити настройки енергоспоживання в сервері BIOS. Багато адміністраторів включають в BIOS режим High Performance і цим відключають технології енергозбереження C-states і P-states. У сучасних процесорах Intel використовується технологія Turbo Boost, яка збільшує частоту окремих ядер процесора за рахунок інших ядер. Але вона працює лише за включених технологій енергозбереження. Якщо ми їх відключаємо, процесор не може зменшити енергоспоживання ядер, які не навантажені.
VMware рекомендує не відключати технології енергозбереження на серверах, а вибирати режими, які максимально віддають керування енергоспоживанням гіпервізору. При цьому в налаштуваннях енергоспоживання гіпервізора необхідно вибрати High Performance.
Якщо у вас в інфраструктурі окремі ВМ (або ядра ВМ) потребують підвищеної частоти CPU, коректне налаштування енергоспоживання може значно покращити їхню продуктивність.
CPU Ready (Readiness)
Якщо ядро ВМ (vCPU) перебуває у стані Ready, воно не виконує корисної роботи. Такий стан виникає, коли гіпервізор не знаходить вільного фізичного ядра, на яке можна призначити процес vCPU віртуальної машини.
Як аналізувати? Зазвичай, якщо ядра віртуальної машини знаходяться в стані Ready більше 10% часу, то ви помітите проблеми з продуктивністю. Простіше кажучи, більше 10% часу ВМ чекає на доступність фізичних ресурсів.
У vCenter можна переглянути 2 лічильники, пов'язані з CPU Ready:
- Readiness,
- Готовий.
Значення обох лічильників можна подивитися як по всій ВМ, так і окремих ядрах.
Readiness показує значення одразу у відсотках, але тільки в Real-time (дані за останню годину, інтервал вимірювань 20 секунд). Цей лічильник краще використовувати лише для пошуку проблем «за гарячими слідами».
Значення лічильника Ready можна переглянути також в історичній перспективі. Це корисно для встановлення закономірностей та більш глибокого аналізу проблеми. Наприклад, якщо у віртуальної машини починаються проблеми з продуктивністю в певний час, можна зіставити інтервали повішеного значення CPU Ready із загальним навантаженням на сервер, де дана ВМ працює, і вжити заходів щодо зниження навантаження (якщо DRS не впорався).
Ready, на відміну від Readiness, показується не у відсотках, а мілісекундах. Це лічильник типу Summation, тобто він показує скільки часу за період вимірювання ядро ВМ знаходилося в стані Ready. Перевести це значення у відсотки можна за нескладною формулою:
(CPU ready summation value / (Chart default update interval in seconds * 1000)) * 100 = CPU ready %
Наприклад, для ВМ на графіку нижче пікове значення Ready на всю віртуальну машину вийде так:
При підрахунку значення Ready у відсотках варто звертати увагу на два моменти:
- Значення Ready по всій ВМ – це сума 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 %
Тут також потрібно звертати увагу на кількість ядер на ВМ та інтервал вимірювання.
У стані сostop ядро не виконує корисної роботи. При правильному підборі розміру ВМ та нормальному навантаженні на сервер лічильник зі-stop має бути близьким до нуля.
В даному випадку навантаження явно ненормальне:)
Що робити? Якщо одному гіпервізорі працюють кілька ВМ з великою кількістю ядер і є перепідписка по CPU, то лічильник co-stop може зрости, що призведе до проблем із продуктивністю даних ВМ.
Також co-stop зросте, якщо для активних ядер однієї ВМ використовуються треди на одному фізичному ядрі сервера із включеним hyper-treading. Така ситуація може виникнути, наприклад, якщо ВМ більше ядер, ніж фізично є на сервері, де вона працює, або якщо для ВМ включено налаштування «preferHT». Про це налаштування можна прочитати .
Щоб уникнути проблем із продуктивністю ВМ через високий со-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 (Number of Worlds) - Кількість процесів у групі. Щоб розкрити групу та побачити метрики для кожного процесу (наприклад, для кожного ядра багатоядерної ВМ), натисніть “e”. Якщо групі більше одного процесу, то значення метрик групи дорівнює сумі метрик окремих процесів.
%USED – скільки циклів CPU сервера використовує процес чи група процесів.
%RUN – скільки часу у період вимірювання процес перебував у стані RUN, тобто. виконував корисну роботу. Відрізняється від %USED тим, що не враховує hyper-threading, frequency scaling та час, витрачений на системні завдання (%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 – скільки часу за період вимірювання процес перебував у стані сostop.
%MLMTD – скільки часу за період вимірювання vCPU перебував у стані Ready через встановлений ліміт ресурсів.
%WAIT + %RDY + %CSTP + %RUN = 100% – ядро ВМ постійно перебуває у одному з цих чотирьох станів.
CPU на гіпервізорі
У vCenter є також лічильники продуктивності CPU для гіпервізора, але вони не становлять нічого цікавого - це просто сума лічильників по всіх ВМ на сервері.
Найзручніше дивитися стан CPU на сервері на вкладці Summary:
Для сервера, як і для віртуальної машини, є стандартний Alarm:
При високому навантаженні на CPU сервера у ВМ, що працюють на ньому, починаються проблеми з продуктивністю.
В ESXTOP дані про завантаження CPU сервера представлені у верхній частині екрана. Крім стандартного CPU load, який малоінформативний для гіпервізорів, є ще три метрики:
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 на сервері. Якщо на ВМ високий Ready, зменште перепідписку по CPU.
Неправильна NUMA-топологія великих ВМ. NUMA-топологія, яку бачить ВМ (vNUMA), має відповідати NUMA-топології сервера (pNUMA). Про діагностику та можливі варіанти вирішення цієї проблеми написано, наприклад, у книзі . Якщо не хочете заглиблюватись і у вас немає ліцензійних обмежень по ОС, встановленої на ВМ, робіть на ВМ багато віртуальних сокетів по одному ядру. Багато не втратите 🙂
На цьому про CPU у мене все. Задавайте питання. У наступній частині розповім про оперативну пам'ять.
Корисні посилання
Джерело: habr.com