Які лічильники нас цікавлять і порогові значення

Спочатку наведу зведену таблицю найважливіших лічильників, порогових значень їх показань і короткий опис (табл 61) Потім послідовно торкнуся нюансів кожної з підсистем сервера в разі віртуалізації і більш докладного опису лічильників

Перераховані в цій таблиці значення є пороговими, в тому сенсі що свідчення вище (нижче) наведених ненормальні і можуть говорити про брак ресурсів тій чи іншій підсистеми

Моніторинг достатності ресурсів

Таблиця 61 Важливі лічильники та їх порогові значення

Підсистема

Лічильник

Значення

Опис, можлива причина проблеми

CPU

%RDY

10*

кіл-у vCPU

Черга до процесора ВМ не вистачає ресурсів процесора

CPU

%CSTP

3

Накладні витрати на многопроцессорную ВМ Зменшіть число vCPU цієї ВМ, або число vCPU на сервері де вона працює

CPU

%MLMTD

0

Якщо більше 0, то можливо ВМ вперлася в Limit по процесору

CPU

%SWPWT

5

ВМ очікує читання сторінок з файлу підкачки Можливо, ВМ не вистачає фізичної памяті

MEM

MCTLSZ (I)

1

Якщо більше 0, значить механізм Balloon віднімає память у гостьовій ОС

MEM

SWCUR (J)

1

Якщо більше 0, значить частина памяті ВМ у файлі підкачки VMkernel

MEM

CACHEUSD

1

Якщо більше 0, значить частина памяті ВМ віднімається механізмом memory compression

MEM

ZIP/s

0

Якщо більше 0, значить ВМ використовує память в кеші memory compression

MEM

UNZIP/s

0

Якщо більше 0, значить ВМ використовує память в кеші memory compression

MEM

SWR/s (J)

1

Читання з файлу підкачки Якщо більше 0, значить файл підкачки використовується

MEM

SWW/s (J)

1

Запис у своп-файл Якщо більше 0, значить своп-файл використовується

DISK

GAVG (H)

25

Затримки для гостьової ОС Це сума лічильників «DAVG» і «KAVG»

DISK

DAVG (H)

25

Затримки пристрої зберігання Високе значення цього лічильника говорить про затримки з боку системи зберігання

DISK

KAVG (H)

2

Затримки на рівні гіпервізора

DISK

ABRTS/s

1

Відмови ініційовані гостьовий ОС (ВМ) із за того, що СГД не відповідає Для Windows це відбувається через 60 секунд, за замовчуванням Можуть бути викликані відмовою шляхів до LUN, або проблемами в роботі multipathing

DISK

QUED (F)

1

Перевищено величина черги команд

DISK

RESETS/s (K)

1

Число скидання SCSI команд в секунду

DISK

CONS/s

20

Число конфліктів SCSI reservation в секунду Якщо відбувається занадто багато конфліктів, продуктивність СГД може деградувати із за втрат часу внаслідок резервування LUN то одним, то іншим сервером

NET

%DRPTX

1

Відкинуті передані пакети Можливо, мережа перевантажена

NET

%DRPRX

1

Відкинуті прийняті пакети Можливо, мережа перевантажена

Отже, ми зіткнулися з недостатньою продуктивністю сервера Не в процесорі чи справа Якщо мова йде про фізичному сервері, то найпростіший шлях – це відкрити Task Manager і подивитися на завантаження процесора (рис 651)

Однак що означає 100%-ва завантаження процесора

Формально вона означає наступне: на цьому процесорі немає вільних тактів, на яких працює процес idle (бездіяльність системи) У випадку роботи ОС на фізичному сервері це зазвичай і означає, що ресурсів процесора недостатньо

Рис 651 Менеджер процесів навантаженого сервера

У разі ж віртуальної машини гостьова ОС не має доступу до управління ресурсами фізичних процесорів Управляє доступом до них гіпервізор, і саме гіпервізор виділяє або не виділяє процесорний час для ВМ

Таким чином, 100%-ва завантаження процесора всередині ВМ означає, що гостьова ОС не бачить вільних тактів процесора Але не факт, що їх немає на физи зації процесорі, – може бути, їх гіпервізор НЕ показує, а видає рівно стільки процесорного часу, скільки готова задіяти гостьова ОС

Визначати ж, чи вистачає процесорних тактів ВМ або ж гіпервізор їй достатньо не видає, потрібно по-іншому Основних шляхів два – скористатися закладкою Perfomance для ВМ в клієнті vSphere або консольної утилітою esxtop (resxtop у разі використання vSphere CLI)

Які лічильники нам доступні Фактично ВМ для гіпервізора – це як процес для звичайної операційної системи І лічильники дуже схожі Основні тут:

Q usage – скільки процесорних ресурсів ВМ задіяла Виконана

робота Не з точки зору гостьовий ОС, а з точки зору гіпервізора Доступний в різних одиницях виміру, дивлячись де ми і як дивимося свідчення цього лічильника Може показуватися в мегагерцах, відсотках (Від продуктивності одного LCPU) і мілісекундах (процесорного часу)

Q wait – стільки часу зайняло очікування введення / виводу

Q ready – найважливіший у даному контексті лічильник Він показує, на скільки процесорного часу у ВМ залишилося незробленої роботи

Моніторинг достатності ресурсів

У кожен момент часу ВМ готова виконати якусь роботу Ця робота ділиться на зроблену і незроблену, або CPU usage і CPU ready Саме високий показник CPU ready говорить про те, що ВМ не вистачає ресурсів процесора, – робота у ВМ є, але гіпервізор під неї не виділяє процесор

Тепер поговоримо про те, чому CPU ready може бути високий і як з цим

боротися

Поверніться до рис 640

На графіку ми бачимо, що за останній квант часу моніторингу процесор номер 0 цієї ВМ:

Q  Usage – Виконував корисну роботу 4351 мілліcекунду

Q  Wait – 14 873 мілліcекунди процесор перебував у стані wait, тобто очікування закінчення процесів введення / виводу Висновок: у цієї ВМ проблеми зі швидкістю доступу до дисків або до мережі Як моніторити диски і мережа – далі Також є окремий лічильник swap wait time Він показує очікування операції з файлом підкачки VMkernel Це час входить в wait

Q  Ready – Гостьова ОС хотіла виконати роботу, але гіпервізор не дав достатньо процесорного часу на це – ще 930 мілісекунд Висновок – для цієї ВМ не вистачає процесорних ресурсів як таких

Зверніть увагу У CPU Ready показується сума цього показника для всіх процесорів віртуальної машини Тобто CPU Ready = 20 для чотирьохпроцесорній ВМ може означати чергу CPU Ready = 5 для кожного з процесорів, що є нормальним Але можливо, що проблеми у якогось одного віртуального процесора Щоб визначити це, перегляньте дані по кожному процесору

Таким чином, чому CPU ready може бути високим Варіантів, в общемто, декілька

По-перше, можливо, що ресурсів процесора сервера в принципі недостатньо на всі ВМ Наша ВМ претендує на якусь частку у відповідності з налаштуваннями reservation і shares, але цієї частки їй не вистачає

Рішення – збільшити кількість доступних ресурсів Це можна зробити:

Q вимкнувши або перенісши на інші сервери частина ВМ

Q перенісши на більш вільний сервер цю ВМ

Q збільшивши її reservation або shares

Q знизивши reservation або shares інших ВМ

Окремий випадок попереднього пункту – коли на самому сервері вільні ресурси є, але не вистачає ресурсів в пулі ресурсів, де працює ця ВМ

Рішення:

Q ті ж варіанти, що і в попередньому списку

Q збільшити частку ресурсів цього пулу

Q понизити частку ресурсів інших пулів

Ще один окремий випадок – на самому сервері ресурсів процесора в достатку, але ВМ не вистачає всіх тих ресурсів, що гіпервізор може їй дати Нагадаю, що один vCPU працює на одному, і тільки на одному LCPU Це означає, що однопро-

цессорная ВМ як максимум може задіяти ресурси одного ядра сервера Двопроцесорна – двох ядер і т д Виходить, що якщо ВМ, наприклад, однопроцесорна і додатка не вистачає тієї продуктивності, що може дати одне ядро, ви отримаєте високий CPU ready

Рішення – дати ВМ більше віртуальних процесорів Які нюанси можуть

тут нас чекати:

Q в одній ВМ може бути не більше восьми vCPU, коли ESX (i) має Enterprise Plus ліцензію І не більше чотирьох в усіх інших, включаючи безоплатну ліцензію, випадках

Q додаток у ВМ повинно бути багатопотоковим, щоб вийшло вос-

користуватися другим і далі vCPU

Q використовувана в ВМ ОС або додаток можуть мати власні обмеження на кількість підтримуваних процесорів Можлива ситуація, коли з погляду ESX (i) ми можемо видати 8 (наприклад) процесорів для ВМ, а ПО всередині не може їх задіяти через свої технічних або ліцензійних обмежень Це можна обійти за допомогою експериментальної налаштування у файлі налаштувань (* Vmx) ВМ:

cpuidcoresPerSocket  =  X

де X – це число ядер в сокеті віртуальної машини Таким чином, якщо X = 2 і число процесорів у ВМ = 8, то гостьова ОС побачить не 8 одноядер них процесорів, а 4 двоядерних

Q ще одна потенційна причина того, що ВМ не виділяються такти, хоча

вони і є вільні, – це налаштування limit для процесорів ВМ Рішення – збільшити limit

Із загальних рекомендацій слід зазначити наступну – завжди налаштовуйте ВМ на використання якомога меншої кількості віртуальних процесорів Тільки якщо ви однозначно впевнені, що не вистачає саме продуктивності однієї фізичної ядра, то видавайте ВМ другий (і т д) віртуальний процесор Переконайтеся, що продуктивність дійсно збільшилася Ця рекомендація є наслідком того, що з ростом числа vCPU для ВМ зменшується ефективність їх використання та ростуть накладні витрати

Наведені тут рекомендації щодо вирішення проблем з продуктивністю для процесора є найпростішими Існують і більш глибокі методики, типу настройки ОС і додатків на використання великих сторінок памяті або зниження частоти timer interrupt для гостьової ОС Тут я їх не наводжу в силу їх більшої залежності від конкретного випадку, конкретної гостьової ОС та іншого, так що див документацію Наприклад, рекомендую звернутися до документа «Performance Troubleshooting for VMware vSphere 4» (http://communities vmwarecom/docs/DOC-10352)

Для оперативної памяті показником недостатності ресурсів є витіснення віртуальної машини з памяті сервера у файл підкачки Головний нюанс полягає в тому, що використання VMkernel Swap, memory compression і

Моніторинг достатності ресурсів

balloon зсередини ВМ визначити неможливо Тому знову ж необхідно дивитися «зовні», з боку гіпервізора

Виділіть ВМ ⇒ закладкаPerfomance Chart Options У лівій частині від-

крившееся вікна виберіть Memory і оберіть період часу Праворуч до-

Ступні лічильники:

Q  Consumed – Стільки памяті для ВМ виділено з фізичної памяті сервера

Q  Granted – Це кількість памяті сервер виділив для ВМ Сторінка не виділяється, поки з боку ВМ не буде хоча б одного запиту для неї Видані сторінки можуть бути відібрані механізмами vmmemctl і VMkernel swap

Q  Active – З такого обсягу памяттю ВМ активно працювала в момент останнього опитування Виділена, але не активна память може бути відібрана у ВМ без шкоди для її продуктивності

Q  Balloon – Стільки памяті віднімається у ВМ механізмом balloon

Q  Zipped memory – Стільки памяті знаходиться в стислому вигляді, в буфері механізму memory compression

Q  Swapped – Стільки памяті поміщено в VMkernel swap

Q  Swap in rate і Swap out rate – Активність використання файлу підкачки

Навіть великі значення в balloon і swapped можуть не означати проблеми продуктивності конкретної ВМ – цими механізмами гіпервізор може віднімати у ВМ память, яку та в даний момент не використовує А чи потрібна ВМ та память, що ESX (i) цими механізмами відбирає, показують дані лічильники

Таким чином, свідченням браку памяті є стабільно високі показники balloon, zipped і swapped укупі з високими показниками Swap in rate і Swap out rate

З продуктивністю дискової підсистеми у разі віртуальних машин все йде приблизно так само, як і для машин фізичних Специфіка роботи з дисковою підсистемою в разі віртуалізації полягає в тому, що від гостьової ОС до безпосередньо дисків задіяно багато етапів:

1 Гостьова ОС спілкується з драйвером SCSI контролера (віртуального)

2 Він передає команди SCSI-контролеру

3 Вони перехоплюються гіпервізором, гіпервізор формує чергу команд із звернень до диску своїх ВМ і передає її драйверу контролера Це може бути драйвер HBA, або служба NFS, або програмний iSCSI ініціатор

4 Залежно від варіанту ці команди швидше або трохи повільніше потрапляють на контролер, HBA або NIC

5 Запит йде на систему зберігання і потім у зворотному порядку повертається до гостьової ОС

Зазвичай вузьким місцем стає етап № 4 або 5 У якихось ситуаціях ми можемо впертися в пропускну здатність каналу передачі даних У яких-

то – в кількість операцій введення / виводу, які здатна обробити система зберігання

Якщо повернутися до таблиці важливих лічильників, то для дискової підсистеми:

Q GAVG – це етапи з другого по пятий

Q KAVG – це етапи три і чотири

Q DAVG – це етап пять

Дані по навантаженню на дискову підсистему нам можуть надати клієнт vSphere, esxtop і утиліта vscsiStats Остання надає більш детальні і низькорівневі дані Детальна інформація про неї наведена за посиланням http://communitiesvmwarecom/docs/DOC-10095

У великих інфраструктурах часто має сенс звертатися до статистики навантаження з боку системи зберігання СГД високого рівня мають соответству ющіе можливості

У інфраструктурах будь-якого розміру уважно вивчайте документацію з налаштування наявної СГД під ESX (i) – проблеми продуктивності через неправильну налаштування надзвичайно образливі

Поганими показниками для системи зберігання є високі показники латентності і дискової черги

Для мережі нас в першу чергу цікавить кількість відкинутих пакетів

Це лічильники droppedRx і droppedTx в графічному інтерфейсі, або% DRPTX і

% DRPRX в esxtop

Високі показники цих лічильників свідчать про погану виробляй ності мережі

Однак у більшості випадків проблеми з продуктивністю мережі викликані зовнішньої щодо серверів ESX (i) частиною інфраструктури

Джерело: Міхєєв М О Адміністрування VMware vSphere 41 – М: ДМК Пресс, 2011 – 448 с: Ил

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*