Ak spravujete virtuálnu infraštruktúru založenú na VMware vSphere (alebo inom technologickom zásobníku), pravdepodobne často počujete sťažnosti používateľov: „Virtuálny počítač je pomalý!“ V tejto sérii článkov budem analyzovať metriky výkonu a poviem vám, čo a prečo sa spomaľuje a ako zabezpečiť, aby sa nespomalil.
Zvážim nasledujúce aspekty výkonu virtuálneho počítača:
- CPU,
- RAM,
- DISK,
- Network.
Začnem CPU.
Na analýzu výkonu budeme potrebovať:
- Počítadlá výkonu vCenter – počítadlá výkonu, ktorých grafy je možné prezerať prostredníctvom klienta vSphere. Informácie o týchto počítadlách sú dostupné v akejkoľvek verzii klienta („hrubý“ klient v C#, webový klient vo Flex a webový klient v HTML5). V týchto článkoch použijeme screenshoty z C# klienta, len preto, že vyzerajú lepšie v miniatúre :)
- ESXTOP – pomôcka, ktorá sa spúšťa z príkazového riadku ESXi. S jeho pomocou môžete získať hodnoty počítadiel výkonu v reálnom čase alebo nahrať tieto hodnoty za určité obdobie do súboru .csv na ďalšiu analýzu. Ďalej vám poviem viac o tomto nástroji a poskytnem niekoľko užitočných odkazov na dokumentáciu a články na túto tému.
Niektoré teórie
V ESXi je za prevádzku každého vCPU (virtual machine core) zodpovedný samostatný proces – svet v terminológii VMware. Existujú aj servisné procesy, ale z hľadiska analýzy výkonu VM sú menej zaujímavé.
Proces v ESXi môže byť v jednom zo štyroch stavov:
- beh – proces vykonáva nejakú užitočnú prácu.
- Počkajte – proces nevykonáva žiadnu prácu (nečinný) alebo čaká na vstup/výstup.
- Costop – stav, ktorý sa vyskytuje vo viacjadrových virtuálnych strojoch. Vyskytuje sa, keď plánovač CPU hypervízora (ESXi CPU Scheduler) nemôže naplánovať súčasné spustenie všetkých aktívnych jadier virtuálnych strojov na jadrách fyzického servera. Vo fyzickom svete všetky jadrá procesora pracujú paralelne, hosťujúci OS vo vnútri VM očakáva podobné správanie, takže hypervízor musí spomaliť jadrá VM, ktoré majú schopnosť rýchlejšie dokončiť svoj cyklus hodín. V moderných verziách ESXi používa plánovač CPU mechanizmus nazývaný uvoľnené spoločné plánovanie: hypervízor zvažuje medzeru medzi „najrýchlejším“ a „najpomalším“ jadrom virtuálneho stroja (zošikmenie). Ak medzera prekročí určitú hranicu, rýchle jadro sa dostane do stavu costop. Ak jadrá virtuálnych počítačov trávia veľa času v tomto stave, môže to spôsobiť problémy s výkonom.
- Pripravený – proces sa dostane do tohto stavu, keď hypervízor nie je schopný alokovať zdroje na jeho vykonanie. Vysoké hodnoty pripravenosti môžu spôsobiť problémy s výkonom VM.
Základné počítadlá výkonu CPU virtuálneho stroja
Vyuzitie procesora, %. Zobrazuje percento využitia procesora za dané obdobie.
Ako analyzovať? Ak VM sústavne využíva CPU na 90 % alebo sú špičky až do 100 %, potom máme problémy. Problémy môžu byť vyjadrené nielen v „pomalej“ prevádzke aplikácie vo vnútri VM, ale aj v nedostupnosti VM cez sieť. Ak monitorovací systém ukazuje, že VM pravidelne vypadáva, venujte pozornosť vrcholom v grafe využitia CPU.
Existuje štandardný alarm, ktorý ukazuje zaťaženie CPU virtuálneho počítača:
Čo robiť? Ak využitie CPU virtuálneho počítača neustále stúpa, môžete uvažovať o zvýšení počtu vCPU (bohužiaľ, nie vždy to pomôže) alebo o presunutí virtuálneho počítača na server s výkonnejšími procesormi.
Využitie CPU v MHz
V grafoch využitia vCenter v % vidíte len pre celý virtuálny stroj, nie sú k dispozícii žiadne grafy pre jednotlivé jadrá (v Esxtop sú hodnoty % pre jadrá). Pre každé jadro môžete vidieť využitie v MHz.
Ako analyzovať? Stáva sa, že aplikácia nie je optimalizovaná pre viacjadrovú architektúru: využíva iba jedno jadro na 100% a ostatné sú nečinné bez zaťaženia. Napríklad pri predvolených nastaveniach zálohovania spustí MS SQL proces iba na jednom jadre. V dôsledku toho sa zálohovanie spomaľuje nie kvôli nízkej rýchlosti diskov (na tú sa používateľ spočiatku sťažoval), ale kvôli tomu, že si procesor nevie poradiť. Problém bol vyriešený zmenou parametrov: zálohovanie začalo prebiehať paralelne vo viacerých súboroch (resp. vo viacerých procesoch).
Príklad nerovnomerného zaťaženia jadier.
Existuje aj situácia (ako v grafe vyššie), keď sú jadrá zaťažované nerovnomerne a niektoré z nich majú vrcholy 100%. Rovnako ako pri načítaní iba jedného jadra nebude fungovať alarm pre využitie CPU (je pre celý VM), ale vyskytnú sa problémy s výkonom.
Čo robiť? Ak softvér vo virtuálnom stroji zaťažuje jadrá nerovnomerne (využíva len jedno jadro alebo časť jadier), nemá zmysel zvyšovať ich počet. V tomto prípade je lepšie presunúť VM na server s výkonnejšími procesormi.
Môžete tiež skúsiť skontrolovať nastavenia spotreby energie v systéme BIOS servera. Mnohí správcovia povoľujú v systéme BIOS režim vysokého výkonu a tým deaktivujú technológie šetrenia energie stavov C a P. Moderné procesory Intel využívajú technológiu Turbo Boost, ktorá zvyšuje frekvenciu jednotlivých jadier procesora na úkor ostatných jadier. Funguje to však iba vtedy, keď sú zapnuté technológie na úsporu energie. Ak ich zakážeme, procesor nedokáže znížiť spotrebu jadier, ktoré nie sú zaťažené.
VMware odporúča nevypínať technológie na úsporu energie na serveroch, ale zvoliť režimy, ktoré ponechajú správu napájania čo najviac na hypervízor. V tomto prípade musíte v nastaveniach spotreby energie hypervízora vybrať možnosť Vysoký výkon.
Ak máte vo svojej infraštruktúre jednotlivé virtuálne počítače (alebo jadrá virtuálnych počítačov), ktoré vyžadujú zvýšenú frekvenciu CPU, správne nastavenie spotreby energie môže výrazne zlepšiť ich výkon.
Procesor pripravený
Ak je jadro VM (vCPU) v stave Pripravené, nevykonáva užitočnú prácu. Tento stav nastane, keď hypervízor nenájde voľné fyzické jadro, ku ktorému je možné priradiť proces vCPU virtuálneho počítača.
Ako analyzovať? Zvyčajne, ak sú jadrá virtuálneho počítača v stave Pripravené viac ako 10 % času, zaznamenáte problémy s výkonom. Jednoducho povedané, viac ako 10 % času VM čaká na dostupnosť fyzických prostriedkov.
Vo vCenter si môžete pozrieť 2 počítadlá súvisiace s CPU Ready:
- pripravenosť,
- Ready.
Hodnoty oboch počítadiel je možné zobraziť pre celý VM aj pre jednotlivé jadrá.
Pripravenosť zobrazuje hodnotu okamžite v percentách, ale iba v reálnom čase (údaje za poslednú hodinu, interval merania 20 sekúnd). Toto počítadlo je lepšie používať iba na hľadanie problémov „v pätách“.
Hotové hodnoty počítadiel možno vidieť aj z historického hľadiska. Je to užitočné pri vytváraní vzorcov a pri hlbšej analýze problému. Napríklad, ak virtuálny počítač začne mať problémy s výkonom v určitom čase, môžete porovnať intervaly hodnoty CPU Ready s celkovým zaťažením servera, na ktorom je tento VM spustený, a prijať opatrenia na zníženie zaťaženia (ak DRS zlyhá).
Pripravený, na rozdiel od Readiness, sa nezobrazuje v percentách, ale v milisekundách. Toto je počítadlo typu Summation, to znamená, že ukazuje, ako dlho počas obdobia merania bolo jadro VM v stave Pripravené. Túto hodnotu môžete previesť na percentá pomocou jednoduchého vzorca:
(CPU ready summation value / (predvolený interval aktualizácie grafu v sekundách * 1000)) * 100 = CPU ready %
Napríklad pre VM v grafe nižšie bude maximálna hodnota Ready pre celý virtuálny počítač nasledovná:
Pri výpočte percenta pripravenosti by ste mali venovať pozornosť dvom bodom:
- Hodnota Ready pre celý VM je súčet Ready medzi jadrami.
- Interval merania. V reálnom čase je to 20 sekúnd a napríklad v denných grafoch je to 300 sekúnd.
Pri aktívnom odstraňovaní problémov možno tieto jednoduché body ľahko prehliadnuť a stratiť drahocenný čas riešením neexistujúcich problémov.
Vypočítajme Ready na základe údajov z grafu nižšie. (324474/(20*1000))*100 = 1622 % pre celý VM. Ak sa pozriete na jadrá, nie je to také strašidelné: 1622/64 = 25 % na jadro. V tomto prípade je úlovok celkom ľahko rozpoznateľný: hodnota Ready je nereálna. Ale ak hovoríme o 10–20% pre celý VM s niekoľkými jadrami, potom pre každé jadro môže byť hodnota v normálnom rozsahu.
Čo robiť? Vysoká hodnota Ready znamená, že server nemá dostatok procesorových prostriedkov na normálnu prevádzku virtuálnych strojov. V takejto situácii zostáva len znížiť nadmerné predplatné procesorom (vCPU:pCPU). Je zrejmé, že sa to dá dosiahnuť znížením parametrov existujúcich VM alebo migráciou časti VM na iné servery.
Spoluzastávka
Ako analyzovať? Toto počítadlo je tiež typu Summation a prevádza sa na percentá rovnakým spôsobom ako Ready:
(hodnota súčtu spoločného zastavenia procesora / (predvolený interval aktualizácie grafu v sekundách * 1000 100)) * XNUMX = % spoločného zastavenia procesora
Tu si treba dať pozor aj na počet jadier na VM a interval merania.
V costop stave jadro nevykonáva užitočnú prácu. Pri správnom výbere veľkosti virtuálneho počítača a normálnom zaťažení servera by sa počítadlo spoločného zastavenia malo blížiť k nule.
V tomto prípade je zaťaženie zjavne abnormálne :)
Čo robiť? Ak na jednom hypervízore beží niekoľko virtuálnych počítačov s veľkým počtom jadier a na CPU dôjde k nadmernému odberu, potom sa môže zvýšiť počítadlo spoločného zastavenia, čo povedie k problémom s výkonom týchto virtuálnych počítačov.
Spoluzastavenie sa tiež zvýši, ak aktívne jadrá jedného VM používajú vlákna na jednom jadre fyzického servera s povoleným hyper-treadingom. Táto situácia môže nastať napríklad vtedy, ak má virtuálny počítač viac jadier, ako je fyzicky dostupných na serveri, kde beží, alebo ak je pre virtuálny počítač povolené nastavenie „preferHT“. O tomto nastavení si môžete prečítať .
Aby ste sa vyhli problémom s výkonom virtuálneho počítača v dôsledku vysokého spoločného zastavenia, vyberte veľkosť virtuálneho počítača v súlade s odporúčaniami výrobcu softvéru, ktorý je spustený na tomto virtuálnom počítači, a možnosťami fyzického servera, na ktorom virtuálny počítač beží.
Nepridávajte jadrá do rezervy, môže to spôsobiť problémy s výkonom nielen pre samotný VM, ale aj pre jeho susedov na serveri.
Ďalšie užitočné metriky CPU
beh – koľko času (ms) bol vCPU počas obdobia merania v stave RUN, to znamená, že skutočne vykonával užitočnú prácu.
Lenivý – ako dlho (ms) počas obdobia merania bol vCPU v stave nečinnosti. Vysoké hodnoty nečinnosti nie sú problémom, vCPU jednoducho nemalo „čo robiť“.
Počkajte – ako dlho (ms) počas obdobia merania bol vCPU v stave čakania. Keďže IDLE je súčasťou tohto počítadla, vysoké hodnoty čakania tiež neindikujú problém. Ak je však hodnota Wait IDLE nízka, keď je hodnota Wait vysoká, znamená to, že VM čakal na dokončenie I/O operácií, čo zase môže naznačovať problém s výkonom pevného disku alebo akýchkoľvek virtuálnych zariadení VM.
Max obmedzený – ako dlho (ms) počas obdobia merania bolo vCPU v stave Pripravené kvôli nastavenému limitu prostriedkov. Ak je výkon nevysvetliteľne nízky, potom je užitočné skontrolovať hodnotu tohto počítadla a limit CPU v nastaveniach VM. VM môžu mať skutočne limity, o ktorých neviete. Stáva sa to napríklad, keď bol VM klonovaný zo šablóny, na ktorej bol nastavený limit CPU.
Vymeňte počkajte – ako dlho počas obdobia merania čakal vCPU na operáciu s VMkernel Swap. Ak sú hodnoty tohto počítadla nad nulou, potom má VM určite problémy s výkonom. Viac o SWAP si povieme v článku o počítadlách RAM.
ESXTOP
Ak sú počítadlá výkonu vo vCenter dobré na analýzu historických údajov, operačná analýza problému je lepšie vykonať v ESXTOP. Tu sú všetky hodnoty uvedené v hotovej forme (nie je potrebné nič prekladať) a minimálna doba merania je 2 sekundy.
Obrazovka ESXTOP pre CPU sa vyvolá klávesom „c“ a vyzerá takto:
Pre pohodlie môžete stlačením Shift-V ponechať iba procesy virtuálneho počítača.
Ak chcete zobraziť metriky pre jednotlivé jadrá VM, stlačte „e“ a zadajte GID požadovaného VM (30919 na snímke obrazovky nižšie):
Dovoľte mi stručne prejsť stĺpce, ktoré sú štandardne prezentované. Ďalšie stĺpce môžete pridať stlačením „f“.
NWLD (Počet svetov) – počet procesov v skupine. Ak chcete rozbaliť skupinu a zobraziť metriky pre každý proces (napríklad pre každé jadro vo viacjadrovom virtuálnom počítači), stlačte „e“. Ak je v skupine viac ako jeden proces, potom sa hodnoty metrík pre skupinu rovnajú súčtu metrík pre jednotlivé procesy.
%POUŽITÉ – koľko cyklov CPU servera používa proces alebo skupina procesov.
%RUN – ako dlho počas obdobia merania bol proces v stave RUN, t.j. vykonal užitočnú prácu. Od %USED sa líši tým, že neberie do úvahy hyper-threading, frekvenčné škálovanie a čas strávený systémovými úlohami (%SYS).
%SYS – čas strávený systémovými úlohami, napríklad: spracovanie prerušení, I/O, sieťová prevádzka atď. Hodnota môže byť vysoká, ak má VM veľký I/O.
%OVRLP – koľko času fyzické jadro, na ktorom beží proces VM, strávilo úlohami iných procesov.
Tieto metriky spolu súvisia takto:
%POUŽITÉ = %RUN + %SYS - %OVRLP.
Metrika %POUŽITÁ je zvyčajne informatívnejšia.
%ČAKAJTE – ako dlho počas doby merania bol proces v stave čakania. Povolí IDLE.
%NEČINNÉ – ako dlho počas doby merania bol proces v stave NEČINNOSŤ.
%SWPWT – ako dlho počas obdobia merania čakal vCPU na operáciu s VMkernel Swap.
%VMWAIT – ako dlho bol vCPU počas obdobia merania v stave čakania na udalosť (zvyčajne I/O). Vo vCenter sa podobné počítadlo nenachádza. Vysoké hodnoty indikujú problémy s I/O na VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Ak VM nepoužíva VMkernel Swap, potom sa pri analýze problémov s výkonom odporúča pozrieť sa na %VMWAIT, pretože táto metrika nezohľadňuje čas, keď VM nič nerobil (%IDLE).
%RDY – ako dlho počas doby merania bol proces v stave pripravenosti.
%CSTP – ako dlho počas obdobia merania bol proces v stave zastavenia.
%MLMTD – ako dlho počas obdobia merania bolo vCPU v stave Pripravené kvôli nastavenému limitu zdrojov.
%WAIT + %RDY + %CSTP + %RUN = 100 % – jadro VM je vždy v jednom z týchto štyroch stavov.
CPU na hypervízore
vCenter má tiež počítadlá výkonu CPU pre hypervízor, ale nie sú ničím zaujímavé - sú jednoducho súčtom počítadiel pre všetky VM na serveri.
Najpohodlnejší spôsob zobrazenia stavu CPU na serveri je na karte Súhrn:
Pre server, ako aj pre virtuálny stroj, existuje štandardný alarm:
Keď je zaťaženie procesora servera vysoké, virtuálne počítače na ňom spustené začnú mať problémy s výkonom.
V ESXTOP sa údaje o zaťažení CPU servera zobrazujú v hornej časti obrazovky. Okrem štandardného zaťaženia procesora, ktoré nie je pre hypervízory príliš informatívne, existujú ďalšie tri metriky:
CORE UTIL (%) – načítanie fyzického jadra servera. Toto počítadlo ukazuje, koľko času jadro vykonávalo prácu počas obdobia merania.
PCPU UTIL (%) – ak je povolené hyper-threading, potom existujú dve vlákna (PCPU) na fyzické jadro. Táto metrika ukazuje, ako dlho každému vláknu trvalo dokončenie práce.
POUŽITÉ PCPU (%) – rovnako ako PCPU UTIL (%), ale zohľadňuje frekvenčné škálovanie (buď zníženie frekvencie jadra na účely úspory energie, alebo zvýšenie frekvencie jadra vďaka technológii Turbo Boost) a hyper-threading.
PCPU_USED% = PCPU_UTIL% * efektívna frekvencia jadra / nominálna frekvencia jadra.
Na tejto snímke obrazovky je pre niektoré jadrá v dôsledku Turbo Boost hodnota USED väčšia ako 100 %, pretože frekvencia jadra je vyššia ako nominálna.
Niekoľko slov o tom, ako sa berie do úvahy hyper-threading. Ak sa procesy vykonávajú 100 % času na oboch vláknach fyzického jadra servera, zatiaľ čo jadro pracuje na nominálnej frekvencii, potom:
- CORE UTIL pre jadro bude 100 %,
- PCPU UTIL pre obe vlákna bude 100 %,
- POUŽITÝ PCPU pre obe vlákna bude 50 %.
Ak obe vlákna nefungovali 100% času počas obdobia merania, potom počas tých období, keď vlákna pracovali paralelne, sa PCPU POUŽITÉ pre jadrá rozdelí na polovicu.
ESXTOP má tiež obrazovku s parametrami spotreby CPU servera. Tu môžete vidieť, či server používa technológie na úsporu energie: C-stavy a P-stavy. Volané klávesom "p":
Bežné problémy s výkonom procesora
Nakoniec prejdem typické príčiny problémov s výkonom procesora VM a poskytnem krátke tipy na ich riešenie:
Frekvencia taktovania jadra nestačí. Ak nie je možné upgradovať váš VM na výkonnejšie jadrá, môžete skúsiť zmeniť nastavenia napájania, aby Turbo Boost fungovalo efektívnejšie.
Nesprávna veľkosť VM (príliš veľa/málo jadier). Ak nainštalujete málo jadier, dôjde k veľkému zaťaženiu CPU na VM. Ak je toho veľa, chyťte vysoký co-stop.
Veľký nadmerný odber CPU na serveri. Ak má VM vysoký stav Ready, znížte nadmerné prihlásenie na odber CPU.
Nesprávna topológia NUMA na veľkých virtuálnych počítačoch. Topológia NUMA, ktorú vidí VM (vNUMA), sa musí zhodovať s topológiou NUMA servera (pNUMA). Diagnostika a možné riešenia tohto problému sú napísané napríklad v knihe . Ak nechcete ísť hlbšie a nemáte licenčné obmedzenia pre operačný systém nainštalovaný na virtuálnom počítači, vytvorte na virtuálnom počítači veľa virtuálnych soketov, jedno jadro po druhom. Veľa nestratíš :)
To je z mojej strany o CPU všetko. Klásť otázky. V ďalšej časti budem hovoriť o RAM.
Užitočné odkazy
Zdroj: hab.com