Ако администрирате виртуелна инфраструктура базирана на VMware vSphere (или кој било друг технолошки стек), веројатно често слушате поплаки од корисниците: „Виртуелната машина е бавна!“ Во оваа серија на написи ќе ги анализирам метриките на перформансите и ќе ви кажам што и зошто забавува и како да бидете сигурни дека не забавува.
Ќе ги разгледам следните аспекти на перформансите на виртуелната машина:
- Процесор,
- RAM меморија,
- ДИСК,
- Мрежа.
Ќе почнам со процесорот.
За да ги анализираме перформансите ќе ни требаат:
- Бројачи за изведба на vCenter – бројачи на перформанси, чии графикони може да се гледаат преку клиентот vSphere. Информациите за овие бројачи се достапни во која било верзија на клиентот („дебел“ клиент во C#, веб-клиент во Flex и веб-клиент во HTML5). Во овие статии ќе користиме слики од екранот од клиентот C#, само затоа што изгледаат подобро во минијатурно :)
- ESXTOP – алатка која работи од командната линија ESXi. Со негова помош, можете да ги добиете вредностите на бројачите на перформанси во реално време или да ги поставите овие вредности за одреден период во датотека .csv за понатамошна анализа. Следно, ќе ви кажам повеќе за оваа алатка и ќе дадам неколку корисни врски до документацијата и написите на оваа тема.
Малку теорија
Во ESXi, посебен процес - свет во терминологијата на VMware - е одговорен за работата на секој vCPU (јадро на виртуелната машина). Постојат и сервисни процеси, но од гледна точка на анализа на перформансите на VM тие се помалку интересни.
Процесот во ESXi може да биде во една од четирите состојби:
- Испратена – процесот извршува некоја корисна работа.
- Почекајте – процесот не работи (неактивен) или чека влез/излез.
- Костоп – состојба која се јавува во виртуелни машини со повеќе јадра. Тоа се случува кога распоредувачот на процесорот на хипервизорот (ESXi CPU Scheduler) не може да закаже истовремено извршување на сите активни јадра на виртуелната машина на јадрата на физичкиот сервер. Во физичкиот свет, сите јадра на процесорот работат паралелно, гостинскиот оперативен систем во VM очекува слично однесување, па хипервизорот мора да ги успори јадрата на VM кои имаат способност да го завршат својот такт циклус побрзо. Во современите верзии на ESXi, распоредувачот на процесорот користи механизам наречен опуштено ко-закажување: хипервизорот го разгледува јазот помеѓу „најбрзото“ и „најбавното“ јадро на виртуелната машина (искривување). Ако јазот надмине одреден праг, брзото јадро влегува во костоп состојба. Ако јадрата на VM поминуваат многу време во оваа состојба, тоа може да предизвика проблеми со перформансите.
- Подготвен – процесот влегува во оваа состојба кога хипервизорот не може да одвои ресурси за негово извршување. Високите подготвени вредности може да предизвикаат проблеми со перформансите на VM.
Основни бројачи за перформанси на процесорот на виртуелната машина
Употреба на процесорот, %. Го прикажува процентот на користење на процесорот за даден период.
Како да се анализира? Ако VM постојано користи процесор со 90% или има врвови до 100%, тогаш имаме проблеми. Проблемите можат да се изразат не само во „бавното“ работење на апликацијата во VM, туку и во непристапноста на VM преку мрежата. Ако системот за следење покажува дека VM периодично паѓа, обрнете внимание на врвовите во графиконот за употреба на процесорот.
Постои стандарден аларм што го покажува оптоварувањето на процесорот на виртуелната машина:
Што да правам? Ако користењето на процесорот на VM постојано поминува низ покривот, тогаш можете да размислите за зголемување на бројот на vCPU (за жал, ова не секогаш помага) или преместување на VM на сервер со помоќни процесори.
Употреба на процесорот во MHz
Во графиконите на vCenter Usage во % можете да видите само за целата виртуелна машина; нема графикони за поединечни јадра (во Esxtop има % вредности за јадра). За секое јадро можете да видите Употреба во MHz.
Како да се анализира? Се случува апликацијата да не е оптимизирана за повеќејадрена архитектура: користи само едно јадро 100%, а останатите се неактивен без оптоварување. На пример, со стандардните поставки за резервна копија, MS SQL го започнува процесот само на едно јадро. Како резултат на тоа, резервната копија се забавува не поради бавната брзина на дисковите (ова е она на што корисникот првично се пожали), туку затоа што процесорот не може да се справи. Проблемот беше решен со промена на параметрите: резервната копија почна да работи паралелно во неколку датотеки (соодветно, во неколку процеси).
Пример за нерамномерно оптоварување на јадрата.
Исто така, постои ситуација (како на графиконот погоре) кога јадрата се вчитани нерамномерно и некои од нив имаат врвови од 100%. Како и при вчитување на само едно јадро, алармот за користење на процесорот нема да работи (тој е за целиот VM), но ќе има проблеми со перформансите.
Што да правам? Ако софтверот во виртуелната машина ги вчитува јадрата нерамномерно (користи само едно јадро или дел од јадрата), нема смисла да се зголемува нивниот број. Во овој случај, подобро е да го преместите VM на сервер со помоќни процесори.
Може да се обидете да ги проверите и поставките за потрошувачка на енергија во BIOS-от на серверот. Многу администратори го овозможуваат режимот со високи перформанси во BIOS-от и со тоа ги оневозможуваат технологиите за заштеда на енергија C-states и P-states. Современите процесори на Интел користат технологија Turbo Boost, што ја зголемува фреквенцијата на поединечни процесорски јадра на сметка на другите јадра. Но, работи само кога се вклучени технологиите за заштеда на енергија. Ако ги оневозможиме, процесорот не може да ја намали потрошувачката на енергија на јадрата што не се вчитани.
VMware препорачува да не се оневозможуваат технологиите за заштеда на енергија на серверите, туку да се изберат режими што управувањето со енергијата го оставаат на хипервизорот колку што е можно повеќе. Во овој случај, во поставките за потрошувачка на енергија на хипервизорот, треба да изберете High Performance.
Ако имате поединечни VM (или VM-јадра) во вашата инфраструктура за кои е потребна зголемена фреквенција на процесорот, правилното прилагодување на потрошувачката на енергија може значително да ги подобри нивните перформанси.
Подготвен процесор
Ако јадрото на VM (vCPU) е во состојба Подготвено, тоа не врши корисна работа. Оваа состојба се јавува кога хипервизорот не наоѓа слободно физичко јадро на кое може да се додели процесот vCPU на виртуелната машина.
Како да се анализира? Обично, ако јадрата на виртуелната машина се во подготвеност повеќе од 10% од времето, ќе забележите проблеми со перформансите. Едноставно кажано, повеќе од 10% од времето VM чека физичките ресурси да станат достапни.
Во vCenter можете да видите 2 бројачи поврзани со CPU Ready:
- готовност,
- Подготвени
Вредностите на двата бројачи може да се видат и за целото VM и за поединечните јадра.
Подготвеноста ја покажува вредноста веднаш како процент, но само во реално време (податоци за последниот час, интервал на мерење 20 секунди). Подобро е да го користите овој бројач само за да барате проблеми „жешки на петиците“.
Подготвените противвредности може да се гледаат и од историска перспектива. Ова е корисно за воспоставување шеми и за подлабока анализа на проблемот. На пример, ако виртуелната машина почне да искусува проблеми со перформансите во одредено време, можете да ги споредите интервалите на вредноста на CPU Ready со вкупното оптоварување на серверот каде што работи овој VM и да преземете мерки за да го намалите оптоварувањето (ако DRS не успее).
Подготвеноста, за разлика од Подготвеноста, се прикажува не во проценти, туку во милисекунди. Ова е бројач на типот Sumation, односно покажува колку долго во периодот на мерење јадрото на VM било во состојба на подготвеност. Можете да ја претворите оваа вредност во процент користејќи едноставна формула:
(Вредност за сумирање подготвена на процесорот / (стандарден интервал за ажурирање на графиконот во секунди * 1000)) * 100 = подготвен процесор %
На пример, за VM во графиконот подолу, максималната вредност Ready за целата виртуелна машина ќе биде како што следува:
Кога го пресметувате процентот на подготвеност, треба да обрнете внимание на две точки:
- Вредноста Ready за целиот VM е збирот на Ready низ јадрата.
- Мерен интервал. За реално време тоа е 20 секунди, а, на пример, на дневните графикони е 300 секунди.
Со активно решавање проблеми, овие едноставни точки може лесно да се пропуштат и може да се потроши драгоцено време за решавање на непостоечки проблеми.
Да го пресметаме Ready врз основа на податоците од графиконот подолу. (324474/(20*1000))*100 = 1622% за целата ВМ. Ако ги погледнете јадрата, не е толку страшно: 1622 година/64 = 25% по јадро. Во овој случај, уловот е прилично лесно да се забележи: вредноста Ready е нереална. Но, ако зборуваме за 10-20% за целиот VM со неколку јадра, тогаш за секое јадро вредноста може да биде во нормалниот опсег.
Што да правам? Високата вредност на Ready покажува дека серверот нема доволно процесорски ресурси за нормално функционирање на виртуелните машини. Во таква ситуација, останува само да се намали претплатата на процесорот (vCPU:pCPU). Очигледно, ова може да се постигне со намалување на параметрите на постојните VM или со мигрирање на дел од VM на други сервери.
Ко-стоп
Како да се анализира? Овој бројач е исто така од типот Sumation и се претвора во проценти на ист начин како Ready:
(Вредност на сумирање на ко-стоп на процесорот / (стандарден интервал за ажурирање на графиконот во секунди * 1000)) * 100 = прекин на процесорот %
Тука, исто така, треба да обрнете внимание на бројот на јадра на VM и интервалот за мерење.
Во костоп состојба, кернелот не врши корисна работа. Со правилен избор на големината на VM и нормално оптоварување на серверот, бројачот за ко-стоп треба да биде блиску до нула.
Во овој случај, оптоварувањето е јасно ненормално :)
Што да правам? Ако неколку VM со голем број јадра работат на еден хипервизор и има претплата на процесорот, тогаш бројачот за ко-стоп може да се зголеми, што ќе доведе до проблеми со работата на овие VM.
Исто така, co-stop ќе се зголеми ако активните јадра на еден VM користат нишки на едно физичко јадро на серверот со овозможено хипер-газење. Оваа ситуација може да се појави, на пример, ако VM има повеќе јадра отколку физички достапни на серверот каде што работи, или ако поставката „preferHT“ е овозможена за VM. Можете да прочитате за оваа поставка .
За да избегнете проблеми со перформансите на VM поради високото ко-стоп, изберете ја големината на VM во согласност со препораките на производителот на софтверот што работи на овој VM и можностите на физичкиот сервер каде што работи VM.
Не додавајте јадра во резерва; тоа може да предизвика проблеми со перформансите не само за самиот VM, туку и за неговите соседи на серверот.
Други корисни метрики на процесорот
Испратена – колку време (ms) за време на периодот на мерење, vCPU беше во состојба RUN, односно всушност извршуваше корисна работа.
Ајдл – колку долго (ms) за време на периодот на мерење, vCPU беше во состојба на неактивност. Високите вредности на мирување не се проблем, vCPU едноставно немаше „ништо да прави“.
Почекајте – колку долго (ms) за време на периодот на мерење, vCPU беше во состојба на чекање. Бидејќи IDLE е вклучен во овој бројач, високите вредности на чекање исто така не укажуваат на проблем. Но, ако Wait IDLE е ниско кога Чекањето е високо, тоа значи дека VM чекал да завршат операциите I/O, а тоа, пак, може да укаже на проблем со перформансите на хард дискот или било кој виртуелен уред на VM.
Макс ограничен – колку долго (ms) за време на периодот на мерење, vCPU беше во подготвена состојба поради поставеното ограничување на ресурсите. Ако перформансите се необјасниво ниски, тогаш е корисно да се провери вредноста на овој бројач и ограничувањето на процесорот во поставките за VM. VMs навистина може да имаат ограничувања за кои не сте свесни. На пример, ова се случува кога VM е клониран од шаблон на кој е поставено ограничувањето на процесорот.
Размени чекај – колку време во периодот на мерење vCPU чекаше операција со VMkernel Swap. Ако вредностите на овој бројач се над нулата, тогаш VM дефинитивно има проблеми со перформансите. Ќе зборуваме повеќе за SWAP во написот за бројачите на RAM меморија.
ESXTOP
Ако бројачите на перформанси во vCenter се добри за анализа на историски податоци, тогаш оперативната анализа на проблемот е подобро да се прави во ESXTOP. Овде, сите вредности се претставени во готова форма (нема потреба да се преведува ништо), а минималниот период на мерење е 2 секунди.
Екранот ESXTOP за процесорот се повикува со копчето „c“ и изгледа вака:
За погодност, можете да оставите само процеси на виртуелна машина со притискање на Shift-V.
За да ги видите метриките за поединечни VM јадра, притиснете „e“ и внесете го GID на VM од интерес (30919 на сликата од екранот подолу):
Дозволете ми накратко да поминам низ колоните што се стандардно претставени. Дополнителни колони може да се додадат со притискање на „f“.
NWLD (Број на светови) – број на процеси во групата. За да ја проширите групата и да ги видите метриките за секој процес (на пример, за секое јадро во VM со повеќе јадра), притиснете „e“. Ако има повеќе од еден процес во групата, тогаш метричките вредности за групата се еднакви на збирот на метриката за поединечните процеси.
% КОРИСТЕНИ – колку циклуси на процесорот на серверот се користат од процес или група на процеси.
%RUN – колку долго во периодот на мерење процесот бил во состојба RUN, т.е. направи корисна работа. Се разликува од %USED по тоа што не ги зема предвид хипер-нишките, скалирањето на фреквенцијата и времето поминато на системските задачи (%SYS).
%SYS – време поминато на системски задачи, на пример: процесирање на прекини, I/O, мрежна работа итн. Вредноста може да биде висока ако VM има голем I/O.
%OVRLP – колку време физичкото јадро на кое работи процесот на ВМ потроши на задачи од други процеси.
Овие метрики се поврзани една со друга на следниов начин:
%USED = %RUN + %SYS - %OVRLP.
Обично, метриката %USED е поинформативна.
%ЧЕКАЈ – колку долго во периодот на мерење процесот беше во состојба на чекање. Овозможува IDLE.
%НЕДАВНИ – колку долго за време на периодот на мерење процесот беше во состојба на ИДЛЕ.
%SWPWT – колку време во периодот на мерење vCPU чекаше операција со VMkernel Swap.
%VMWAIT – колку долго во периодот на мерење vCPU беше во состојба на чекање за настан (обично I/O). Нема сличен бројач во vCenter. Високите вредности укажуваат на проблеми со I/O на VM.
%ЧЕКАЈ = %VMWAIT + %IDLE + %SWPWT.
Ако VM не користи VMkernel Swap, тогаш кога се анализираат проблемите со перформансите, препорачливо е да се погледне %VMWAIT, бидејќи оваа метрика не го зема предвид времето кога VM не правеше ништо (%IDLE).
%RDY – колку долго во периодот на мерење процесот бил во подготвена состојба.
%CSTP – колку долго во периодот на мерење процесот бил во костоп состојба.
%MLMTD – колку долго за време на периодот на мерење, vCPU беше во подготвеност поради поставеното ограничување на ресурсите.
%WAIT + %RDY + %CSTP + %RUN = 100% – јадрото на VM е секогаш во една од овие четири состојби.
Процесорот на хипервизор
vCenter има и бројачи за перформанси на процесорот за хипервизорот, но тие не се ништо интересно - тие се едноставно збир на бројачи за сите VM на серверот.
Најзгодниот начин за прегледување на статусот на процесорот на серверот е на јазичето Резиме:
За серверот, како и за виртуелната машина, постои стандарден Аларм:
Кога оптоварувањето на процесорот на серверот е големо, VM што работат на него почнуваат да имаат проблеми со изведбата.
Во ESXTOP, податоците за оптоварување на процесорот на серверот се претставени на горниот дел од екранот. Покрај стандардното оптоварување на процесорот, што не е многу информативно за хипервизорите, има уште три метрики:
ОСНОВНА КОРИСТЕНА (%) – вчитување на јадрото на физичкиот сервер. Овој бројач покажува колку време јадрото извршило работа во периодот на мерење.
PCPU UTIL(%) – ако е овозможено хипер-нишки, тогаш има две нишки (PCPU) по физичко јадро. Оваа метрика покажува колку време и требаше на секоја нишка за да се заврши работата.
КОРИСТЕНА ПЦПУ (%) – исто како и PCPU UTIL(%), но го зема предвид скалирањето на фреквенцијата (или намалувањето на основната фреквенција заради заштеда на енергија, или зголемувањето на основната фреквенција поради технологијата Turbo Boost) и хипер-нишките.
PCPU_USED% = PCPU_UTIL% * ефективна основна фреквенција / номинална основна фреквенција.
Во оваа слика од екранот, за некои јадра, поради Turbo Boost, вредноста на USED е поголема од 100%, бидејќи основната фреквенција е повисока од номиналната.
Неколку зборови за тоа како се зема предвид хипер-нишките. Ако процесите се извршуваат 100% од времето на двете нишки од физичкото јадро на серверот, додека јадрото работи на номиналната фреквенција, тогаш:
- CORE UTIL за јадрото ќе биде 100%,
- PCPU UTIL за двете нишки ќе биде 100%,
- PCPU што се користи за двете нишки ќе биде 50%.
Ако двете нишки не работеа 100% од времето за време на периодот на мерење, тогаш во тие периоди кога нишките работеа паралелно, PCPU што се користи за јадрата се дели на половина.
ESXTOP има и екран со параметри за потрошувачка на енергија на процесорот на серверот. Овде можете да видите дали серверот користи технологии за заштеда на енергија: C-states и P-states. Се повикува со копчето „p“:
Вообичаени проблеми со перформансите на процесорот
Конечно, ќе ги разгледам типичните причини за проблеми со перформансите на VM CPU и ќе дадам кратки совети за нивно решавање:
Брзината на јадрото на часовникот не е доволна. Ако не е можно да го надградите вашиот VM на помоќни јадра, можете да се обидете да ги промените поставките за напојување за да направите Turbo Boost да работи поефикасно.
Неправилна големина на VM (премногу/малку јадра). Ако инсталирате неколку јадра, ќе има големо оптоварување на процесорот на VM. Ако има многу, фати висока ко-стоп.
Голема претплата на процесорот на серверот. Ако VM има висока подготвеност, намалете ја претплатата на процесорот.
Неточна NUMA топологија на големи VMs. Топологијата NUMA што ја гледа VM (vNUMA) мора да одговара на NUMA топологијата на серверот (pNUMA). Дијагностика и можни решенија за овој проблем се напишани, на пример, во книгата . Ако не сакате да одите подлабоко и немате ограничувања за лиценцирање на оперативниот систем инсталиран на VM, направете многу виртуелни приклучоци на VM, едно јадро во исто време. Нема да изгубите многу :)
Тоа е сè за мене за процесорот. Поставувајте прашања. Во следниот дел ќе зборувам за RAM меморијата.
Корисни линкови
Извор: www.habr.com