Эгерде сиз виртуалдык инфраструктураны VMware vSphere (же башка технологиялык стек) негизинде башкарсаңыз, анда колдонуучулардан: "Виртуалдык машина жай иштеп жатат!" деген даттанууларды көп угасыз. Бул макалалар сериясында мен өндүрүмдүүлүктүн көрсөткүчтөрүн талдап, эмне жана эмне үчүн ал жайлап жатканын жана ал жайлабагандыгына кантип ынануу керектигин айтып берем.
Мен виртуалдык машинанын иштешинин төмөнкү аспектилерин карап чыгам:
- CPU,
- RAM
- DISK,
- К.
Мен CPU менен баштайм.
натыйжалуулугун талдоо үчүн бизге керек болот:
- vCenter Performance Counters – графиктерин vSphere Client аркылуу көрүүгө мүмкүн болгон аткаруу эсептегичтери. Бул эсептегичтер жөнүндө маалымат кардардын каалаган версиясында жеткиликтүү (C# тилиндеги калың кардар, Flexте веб кардар жана HTML5те веб кардар). Бул макалаларда биз C# кардарынын скриншотторун колдонобуз, анткени алар миниатюрада жакшыраак көрүнөт :)
- ESXTOP – ESXi буйрук сабынан иштей турган утилита. Анын жардамы менен сиз реалдуу убакыт режиминде өндүрүмдүүлүк эсептегичтеринин маанилерин ала аласыз же андан ары талдоо үчүн белгилүү бир мезгилге бул маанилерди .csv файлына жүктөй аласыз. Андан кийин, мен бул курал жөнүндө көбүрөөк айтып берем жана тема боюнча документтерге жана макалаларга бир нече пайдалуу шилтемелерди берем.
теориясынын бир үзүм
ESXiде өзүнчө процесс - VMware терминологиясындагы дүйнө - ар бир vCPU (виртуалдык машинанын өзөгү) иштеши үчүн жооптуу. Тейлөө процесстери да бар, бирок VMнин иштешин талдоо көз карашынан алганда, алар анча кызык эмес.
ESXiдеги процесс төрт абалдын биринде болушу мүмкүн:
- Run – процесс кээ бир пайдалуу иштерди аткарат.
- күтүү – процесс эч кандай жумуш жасабай жатат (бос) же киргизүү/чыгарууну күтүп жатат.
- Costop – көп ядролуу виртуалдык машиналарда пайда болгон шарт. Бул гипервизордун CPU пландоочусу (ESXi CPU Scheduler) физикалык сервердин өзөктөрүндөгү бардык активдүү виртуалдык машина өзөктөрүн бир убакта аткарууну пландаштыра албаганда пайда болот. Физикалык дүйнөдө бардык процессорлордун өзөктөрү параллелдүү иштешет, VM ичиндеги конок ОС окшош жүрүм-турумду күтөт, ошондуктан гипервизор саат циклин тезирээк бүтүрө алган VM өзөктөрүн жайлатышы керек. ESXiнин заманбап версияларында CPU пландоочусу жайбаракат ко-график деп аталган механизмди колдонот: гипервизор "эң ылдам" жана "эң жай" виртуалдык машинанын өзөктөрүнүн ортосундагы ажырымды карайт (кыйшык). Эгерде ажырым белгилүү бир чектен ашып кетсе, тез өзөк костоп абалына кирет. Эгерде VM өзөктөрү бул абалда көп убакыт коротсо, анда ал аткаруу көйгөйлөрүн жаратышы мүмкүн.
- даяр – процесс бул абалга гипервизор аны аткаруу үчүн ресурстарды бөлө албаганда кирет. Жогорку даяр баалуулуктар VM аткаруу көйгөйлөрүн жаратышы мүмкүн.
Негизги виртуалдык машинанын CPU аткаруу эсептегичтери
CPU колдонуу, %. Берилген мезгил үчүн CPU колдонуу пайызын көрсөтөт.
Кантип талдоо керек? Эгерде VM CPU ырааттуу түрдө 90% колдонсо же 100% га чейин чокулар болсо, анда бизде көйгөйлөр бар. Көйгөйлөр VM ичиндеги тиркеменин "жай" иштешинде гана эмес, тармак аркылуу VMдин жеткиликсиздигинде да көрсөтүлүшү мүмкүн. Мониторинг системасы VM мезгил-мезгили менен түшүп жатканын көрсөтсө, CPU колдонуу графигиндеги чокуларга көңүл буруңуз.
Виртуалдык машинанын CPU жүгүн көрсөткөн стандарттуу ойготкуч бар:
Эмне кылуу керек? Эгерде VMнин CPU колдонуусу дайыма чатырдан өтүп жатса, анда vCPU санын көбөйтүү (тилекке каршы, бул дайыма эле жардам бербейт) же VMди күчтүү процессорлору бар серверге жылдыруу жөнүндө ойлонсоңуз болот.
CPU колдонуу MHz
vCenter Usage графиктеринде % менен сиз бүт виртуалдык машинаны гана көрө аласыз; жеке өзөктөр үчүн графиктер жок (Esxtopто өзөктөр үчүн % маанилери бар). Ар бир өзөк үчүн MHz менен колдонууну көрө аласыз.
Кантип талдоо керек? Тиркеме көп ядролуу архитектура үчүн оптималдаштырылган эмес: ал бир гана өзөктү 100% колдонот, ал эми калгандары жүктөлбөй бош турат. Мисалы, демейки камдык орнотуулары менен MS SQL процессти бир гана өзөктө баштайт. Натыйжада, резервдик көчүрүү дисктердин жай ылдамдыгынан эмес (колдонуучу алгач нааразы болгон), бирок процессор туруштук бере албагандыктан басаңдайт. Көйгөй параметрлерди өзгөртүү менен чечилди: камдык көчүрмө бир нече файлдарда (тиешелүүлүгүнө жараша, бир нече процесстерде) параллелдүү иштей баштады.
Ядродогу бирдей эмес жүктүн мисалы.
Ошондой эле жагдай бар (жогорку графиктегидей) өзөктөр бир калыпта эмес жүктөлөт жана алардын айрымдарында 100% чокулары бар. Бир гана өзөктү жүктөө сыяктуу эле, CPU колдонуу сигналы иштебейт (ал бүтүндөй VM үчүн), бирок аткаруу көйгөйлөрү болот.
Эмне кылуу керек? Эгерде виртуалдык машинадагы программалык камсыздоо өзөктөрдү бирдей эмес жүктөсө (бир өзөктү же өзөктөрдүн бир бөлүгүн гана колдонсо), алардын санын көбөйтүүнүн кереги жок. Бул учурда, VMди күчтүү процессорлору бар серверге жылдыруу жакшы.
Сиз ошондой эле сервердин BIOS'унда энергияны керектөө жөндөөлөрүн текшерип көрүңүз. Көптөгөн администраторлор BIOS'та High Performance режимин иштетип, ошону менен C-мамлекеттери жана P-мамлекеттери энергия үнөмдөөчү технологияларды өчүрүшөт. Заманбап Intel процессорлору Turbo Boost технологиясын колдонушат, ал башка өзөктөрдүн эсебинен жеке процессорлордун өзөктөрүнүн жыштыгын жогорулатат. Бирок ал энергияны үнөмдөөчү технологиялар күйгүзүлгөндө гана иштейт. Эгерде биз аларды өчүрө турган болсок, процессор жүктөлбөгөн өзөктөрдүн энергия керектөөсүн азайта албайт.
VMware серверлерде энергияны үнөмдөөчү технологияларды өчүрүүнү эмес, мүмкүн болушунча кубаттуулукту башкарууну гипервизорго калтырган режимдерди тандоону сунуштайт. Бул учурда, гипервизордун энергия керектөө жөндөөлөрүнөн Жогорку Өндүрүмдүүлүктү тандоо керек.
Эгерде сиздин инфраструктураңызда CPU жыштыгын жогорулатууну талап кылган жеке VM (же VM өзөктөрү) бар болсо, электр энергиясын керектөөнү туура жөнгө салуу алардын иштешин олуттуу түрдө жакшыртат.
CPU даяр
Эгерде VM өзөгү (vCPU) Даяр абалда болсо, ал пайдалуу иштерди аткарбайт. Бул шарт гипервизор виртуалдык машинанын vCPU процесси дайындала турган эркин физикалык өзөктү таппай калганда пайда болот.
Кантип талдоо керек? Адатта, эгер виртуалдык машинанын өзөктөрү 10%дан ашык убакытта Даяр абалда болсо, анда сиз аткаруу көйгөйлөрүн байкайсыз. Жөнөкөй сөз менен айтканда, убакыттын 10% ашыгы VM физикалык ресурстардын жеткиликтүү болушун күтөт.
vCenterде сиз CPU Ready менен байланышкан 2 эсептегичти көрө аласыз:
- даярдыгы,
- Даяр.
Эки эсептегичтин маанилерин бүт VM үчүн да, жеке өзөктөр үчүн да көрүүгө болот.
Даярдык маанини дароо пайыз менен көрсөтөт, бирок реалдуу убакыт режиминде гана (акыркы сааттын маалыматтары, өлчөө аралыгы 20 секунд). Бул эсептегичти колдонуу үчүн гана проблемаларды издөө үчүн жакшы "Ысык така".
Даяр эсептегич баалуулуктарды тарыхый көз караш менен кароого болот. Бул үлгүлөрдү түзүү жана маселени терең талдоо үчүн пайдалуу. Мисалы, эгер виртуалдык машина белгилүү бир убакта иштөөдө көйгөйлөргө туш боло баштаса, сиз CPU Даяр маанисинин интервалдарын бул VM иштеп жаткан сервердеги жалпы жүктөм менен салыштырып, жүктөмдү азайтуу үчүн чараларды көрө аласыз (эгерде DRS болсо ийгиликсиз).
Даяр, Даярдыктан айырмаланып, пайыздарда эмес, миллисекунддарда көрсөтүлөт. Бул Summation түрүндөгү эсептегич, башкача айтканда, өлчөө мезгилинде VM өзөгү Даяр абалда канча убакыт болгонун көрсөтөт. Бул маанини жөнөкөй формуланы колдонуп пайызга айландырсаңыз болот:
(CPU даяр суммалоо мааниси / (диаграмманын демейки жаңыртуу аралыгы секундада * 1000)) * 100 = CPU даяр %
Мисалы, төмөнкү графиктеги VM үчүн, бүт виртуалдык машина үчүн эң жогорку Даяр мааниси төмөнкүдөй болот:
Даяр пайызды эсептөөдө эки пунктка көңүл буруу керек:
- Бүтүндөй VM үчүн Даяр мааниси өзөктөр боюнча Даярдын суммасы.
- Өлчөө аралыгы. Реалдуу убакыт үчүн бул 20 секунд, ал эми, мисалы, күнүмдүк диаграммаларда 300 секунд.
Активдүү көйгөйлөрдү чечүү менен, бул жөнөкөй пункттарды оңой эле өткөрүп жиберип, баалуу убакытты болбогон көйгөйлөрдү чечүүгө текке кетирүүгө болот.
Төмөнкү графиктин маалыматтарынын негизинде Даярды эсептеп көрөлү. (324474/(20*1000))*100 = бүт VM үчүн 1622%. Эгерде сиз өзөктөрдү карасаңыз, анда анча деле коркунучтуу эмес: 1622/64 = 25% ар бир ядро. Бул учурда, кармоо оңой эле байкалат: Даяр мааниси реалдуу эмес. Бирок, эгерде биз бир нече өзөгү бар бүтүндөй VM үчүн 10–20% жөнүндө сөз кыла турган болсок, анда ар бир өзөк үчүн маани нормалдуу диапазондо болушу мүмкүн.
Эмне кылуу керек? Жогорку Даяр мааниси серверде виртуалдык машиналардын нормалдуу иштеши үчүн процессордун ресурстары жетишсиз экенин көрсөтүп турат. Мындай кырдаалда процессор (vCPU: pCPU) тарабынан ашыкча жазылууну азайтуу гана калды. Албетте, буга учурдагы VMлердин параметрлерин азайтуу же VMлердин бир бөлүгүн башка серверлерге көчүрүү аркылуу жетүүгө болот.
Ко-стоп
Кантип талдоо керек? Бул эсептегич дагы Сумма түрүнө кирет жана Даяр сыяктуу эле пайыздарга айландырылат:
(CPU биргелешип токтотуу суммасынын мааниси / (диаграмманын демейки жаңыртуу аралыгы секундада * 1000)) * 100 = CPU ко-стоп %
Бул жерде сиз VMдеги өзөктөрдүн санына жана өлчөө аралыгына да көңүл бурушуңуз керек.
Костоп абалында ядро пайдалуу иштерди аткарбайт. VM өлчөмүн туура тандоо жана сервердеги нормалдуу жүктөө менен ко-стоп эсептегичи нөлгө жакын болушу керек.
Бул учурда, жүк ачык анормалдуу эмес :)
Эмне кылуу керек? Эгерде көп сандагы өзөктүү бир нече VM бир гипервизордо иштеп жатса жана CPUда ашыкча жазылуу болсо, анда ко-стоп эсептегичи көбөйүшү мүмкүн, бул бул VMлердин иштешинде көйгөйлөргө алып келет.
Ошондой эле, эгерде бир VMнин активдүү өзөктөрү гипер-тебелөө иштетилген бир физикалык сервер өзөгүндөгү жиптерди колдонсо, ко-стоп көбөйөт. Бул жагдай, мисалы, эгер VM иштеп жаткан серверде физикалык жактан жеткиликтүүдөн көбүрөөк өзөккө ээ болсо же VM үчүн "preferHT" жөндөөсү иштетилген болсо пайда болушу мүмкүн. Бул жөндөө жөнүндө окуй аласыз .
Жогорку ко-стоптон улам VM иштеши менен көйгөйлөрдү болтурбоо үчүн, бул VMде иштеген программалык камсыздоону өндүрүүчүнүн сунуштарына жана VM иштеген физикалык сервердин мүмкүнчүлүктөрүнө ылайык VM өлчөмүн тандаңыз.
Резервге өзөктөрдү кошпоңуз; бул VMдин өзүнө гана эмес, анын сервердеги кошуналарына да иштөө көйгөйлөрүн жаратышы мүмкүн.
Башка пайдалуу CPU көрсөткүчтөрү
Run – өлчөө мезгилинде канча убакыт (мс) vCPU RUN абалында болгон, башкача айтканда, ал иш жүзүндө пайдалуу иштерди аткарып жаткан.
жалкоо – өлчөө мезгилинде канча убакыт (мс) vCPU аракетсиз абалда болгон. Жогорку Idle маанилери көйгөй эмес, vCPU жөн гана "эч нерсе кыла албайт".
күтүү – өлчөө мезгилинде канча убакыт (мс) vCPU Күтүү абалында болгон. IDLE бул эсептегичке киргизилгендиктен, күтүү жогорку маанилери да көйгөйдү билдирбейт. Бирок, күтүү жогорку болгондо, күтүү режими төмөн болсо, бул VM киргизүү/чыгаруу операцияларынын аякташын күтүп жатканын билдирет жана бул, өз кезегинде, катуу дисктин же VMнин кандайдыр бир виртуалдык түзүлүштөрүнүн иштешиндеги көйгөйдү көрсөтүшү мүмкүн.
Макс чектелген – өлчөө мезгилинде канча убакыт (мс) белгиленген ресурстун чегинен улам vCPU Даяр абалда болгон. Эгерде аткаруу түшүнүксүз төмөн болсо, анда бул эсептегичтин маанисин жана VM жөндөөлөрүндөгү CPU чегин текшерүү пайдалуу. VM'дер чындыгында сиз билбеген чектерге ээ болушу мүмкүн. Мисалы, бул VM CPU чеги коюлган шаблондон клондолгондо болот.
Күтө туруңуз – өлчөө мезгилинде vCPU VMkernel Swap менен операцияны канча убакыт күттү. Эгерде бул эсептегичтин маанилери нөлдөн жогору болсо, анда VMдин иштеши боюнча көйгөйлөр бар. RAM эсептегичтери жөнүндө макалада SWAP жөнүндө көбүрөөк сүйлөшөбүз.
ESXTOP
Эгерде vCenter'деги аткаруу эсептегичтери тарыхый маалыматтарды талдоо үчүн жакшы болсо, анда маселенин оперативдүү анализи ESXTOPте жакшыраак жасалат. Бул жерде бардык баалуулуктар даяр түрүндө берилген (эч нерсени которуунун кереги жок) жана минималдуу өлчөө мөөнөтү 2 секунд.
CPU үчүн ESXTOP экраны "c" баскычы менен чакырылат жана мындай көрүнөт:
Ыңгайлуулук үчүн Shift-V баскычтарын басып, виртуалдык машина процесстерин гана калтырсаңыз болот.
Жеке VM өзөктөрүнүн көрсөткүчтөрүн көрүү үчүн, "e" баскычын басып, кызыккан VMнин GID кодун киргизиңиз (төмөндөгү скриншотто 30919):
Мага демейки боюнча берилген тилкелерге кыскача токтоло кетейин. Кошумча тилкелерди "f" баскычын басуу менен кошууга болот.
NWLD (Дүйнөлөрдүн саны) – топтогу процесстердин саны. Топту кеңейтүү жана ар бир процесстин метрикасын көрүү үчүн (мисалы, көп ядролуу VMдеги ар бир өзөк үчүн) “e” баскычын басыңыз. Топто бирден ашык процесс болсо, анда топтун метрикалык маанилери жеке процесстер үчүн көрсөткүчтөрдүн суммасына барабар.
%КОЛДОНУЛГАН – процесс же процесстер тобу тарабынан канча сервердин CPU циклдери колдонулат.
%RUN – өлчөө мезгилинде процесс канча убакытка чейин RUN абалында болгон, б.а. пайдалуу иш кылды. Ал %USEDден айырмаланат, анткени ал гипер-трейдингди, жыштык масштабын жана системалык тапшырмаларга (%SYS) сарпталган убакытты эске албайт.
%SYS – системанын тапшырмаларына сарпталган убакыт, мисалы: үзгүлтүккө учуратуу процесси, киргизүү/чыгаруу, тармактын иштөөсү, ж.б. Эгерде VM чоң киргизүү/чыгарууга ээ болсо, маани жогору болушу мүмкүн.
%OVRLP – VM процесси иштеп жаткан физикалык ядро башка процесстердин тапшырмаларына канча убакыт коротот.
Бул көрсөткүчтөр бири-бири менен төмөнкүчө байланышат:
% КОЛДОНУЛГАН = % RUN + % SYS - % OVRLP.
Адатта %USED метрикасы көбүрөөк маалыматтуу.
% КҮТҮҮ – өлчөө мезгилинде процесс күтүү абалында канча убакыт болгон. IDLEди иштетет.
% БҮГҮН – өлчөө мезгилинде процесс канча убакытка чейин IDLE абалында болгон.
%SWPWT – өлчөө мезгилинде vCPU VMkernel Swap менен операцияны канча убакыт күттү.
%VMWAIT – өлчөө мезгилинде канча убакытка чейин vCPU окуяны күткөн абалда болгон (көбүнчө I/O). vCenterде мындай эсептегич жок. Жогорку маанилер VMдеги киргизүү/чыгаруу көйгөйлөрүн көрсөтөт.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Эгерде VM VMkernel Swap колдонбосо, анда өндүрүмдүүлүк көйгөйлөрүн талдоодо %VMWAITти карап чыгуу сунушталат, анткени бул метрика VM эч нерсе кылбаган убакытты (%IDLE) эске албайт.
%RDY – өлчөө мезгилинде процесс Даяр абалда канча убакытта болгон.
%CSTP – өлчөө мезгилинде процесс канча убакытка созулган.
%MLMTD – өлчөө мезгилинде канча убакытка чейин vCPU белгиленген ресурстун чегинен улам Даяр абалда болгон.
% WAIT + %RDY + %CSTP + %RUN = 100% – VM өзөгү ар дайым ушул төрт абалдын биринде болот.
Гипервизордогу CPU
vCenterде ошондой эле гипервизор үчүн CPU өндүрүмдүүлүгүн эсептегичтери бар, бирок алар эч кандай кызык эмес – алар жөн гана сервердеги бардык VMлер үчүн эсептегичтердин суммасы.
Сервердеги CPU статусун көрүүнүн эң ыңгайлуу жолу Кыскача өтмөктө:
Сервер үчүн, ошондой эле виртуалдык машина үчүн стандарттуу сигнал бар:
Сервердин CPU жүктөмү жогору болгондо, анда иштеген VM'лер аткаруу көйгөйлөрүн башташат.
ESXTOPде сервердин CPU жүктөө маалыматтары экрандын жогору жагында көрсөтүлөт. Гипервизорлор үчүн анча маалымат бербеген стандарттуу CPU жүгүнө кошумча дагы үч көрсөткүч бар:
CORE UTIL(%) – физикалык сервердин өзөгүн жүктөө. Бул эсептегич өлчөө мезгилинде өзөк канча убакыт иштегенин көрсөтөт.
PCPU UTIL(%) – эгерде гипер-жип иштетилген болсо, анда физикалык өзөктө эки жип (PCPU) бар. Бул көрсөткүч ар бир жип ишти бүтүрүү үчүн канча убакыт кеткенин көрсөтөт.
КОЛДОНУЛГАН PCPU(%) – PCPU UTIL(%) менен бирдей, бирок жыштыктын масштабын (же энергияны үнөмдөө максатында негизги жыштыкты азайтуу же Turbo Boost технологиясына байланыштуу негизги жыштыкты көбөйтүү) жана гипер-жыштыкты эске алат.
PCPU_USED% = PCPU_UTIL% * эффективдүү негизги жыштык / номиналдык негизги жыштык.
Бул скриншотто, кээ бир өзөктөр үчүн, Turbo Boost'тун аркасында, USED мааниси 100% дан жогору, анткени негизги жыштык номиналдуудан жогору.
Hyper-threading кантип эске алынганы жөнүндө бир нече сөз. Эгерде процесстер сервердин физикалык өзөгүнүн эки жипинде тең 100% аткарылса, ал эми ядро номиналдык жыштыкта иштеп жатса, анда:
- Ядро үчүн CORE UTIL 100% болот,
- эки жип үчүн PCPU UTIL 100% болот,
- Эки жип үчүн КОЛДОНУЛГАН PCPU 50% түзөт.
Эгерде эки жип тең өлчөө мезгилинде 100% иштебесе, анда жиптер параллелдүү иштеген мезгилде, өзөктөр үчүн КОЛДОНУЛГАН PCPU жарымга бөлүнөт.
ESXTOP ошондой эле сервердин CPU кубаттуулугун керектөө параметрлери бар экранга ээ. Бул жерден сервер энергияны үнөмдөөчү технологияларды колдоноорун көрө аласыз: C-мамлекеттери жана P-мамлекеттери. "p" баскычы менен чакырылат:
Жалпы CPU аткаруу маселелери
Акырында, мен VM CPU иштешиндеги көйгөйлөрдүн типтүү себептерин карап чыгам жана аларды чечүү үчүн кыска кеңештерди берем:
Негизги саат ылдамдыгы жетиштүү эмес. Эгер VM'иңизди күчтүүрөөк өзөктөргө жаңыртуу мүмкүн болбосо, Turbo Boost натыйжалуураак иштеши үчүн кубат орнотууларын өзгөртүүгө аракет кылсаңыз болот.
Туура эмес VM өлчөмү (өтө көп/азыраак өзөктөр). Эгер сиз бир нече өзөктөрдү орнотсоңуз, VMде CPU чоң жүгү болот. көп болсо, бийик ко-стоп кармап.
Серверде CPUга көп жазылуу. VM жогорку даяр болсо, CPU ашыкча жазылууну азайтыңыз.
Чоң VM'лерде туура эмес NUMA топологиясы. VM (vNUMA) көргөн NUMA топологиясы сервердин NUMA топологиясына (pNUMA) дал келиши керек. Диагностика жана бул маселени чечүүнүн мүмкүн болгон жолдору, мисалы, китепте жазылган . Эгерде сиз тереңирээк баргыңыз келбесе жана VMде орнотулган OSде лицензиялык чектөөлөрүңүз жок болсо, VMде көптөгөн виртуалдык розеткаларды, бирден өзөктөрдү жасаңыз. Сиз көп жоготпойсуз :)
Мунун баары мен үчүн CPU жөнүндө. Суроо бериңиз. Кийинки бөлүмдө мен RAM жөнүндө сүйлөшөм.
Пайдалуу шилтемелер
Source: www.habr.com