Калі вы адмініструеце віртуальную інфраструктуру на базе VMware vSphere (ці любога іншага стэка тэхналогій), то напэўна часта чуеце ад карыстачоў скаргі: "Віртуальная машына працуе павольна!". У гэтым цыкле артыкулаў разбяру метрыкі прадукцыйнасці і раскажу, што і чаму «тармозіць» і як зрабіць так, каб не «тармазіла».
Буду разглядаць наступныя аспекты прадукцыйнасці віртуальных машын:
- ЦЭНТРАЛЬНЫ ПРАЦЭСАР,
- RAM,
- 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, гэта значыць уласна выконваў карысную працу.
ўхаластую – колькі часу (мс) за перыяд вымярэння 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