Ak spravujete virtuálnu infraštruktúru založenú na VMware vSphere (alebo akomkoľvek inom technologickom stacku), určite často počujete od používateľov sťažnosti: „Virtuálny stroj funguje pomaly!“. V tejto sérii článkov sa zameriam na metriky výkonu a vysvetlím, čo a prečo „spomaľuje“ a ako to správne nastaviť, aby to „nespomalilo“.
Budú sa analyzovať nasledujúce aspekty výkonu virtuálnych strojov:
- CPU,
- RAM,
- DISK,
- Sieť.
Začnem s CPU.
Na analýzu výkonu budeme potrebovať:
- vCenter Performance Counters – výkonnostné štatistiky, ktorých grafy si môžete pozrieť prostredníctvom vSphere Client. Informácie o týchto štatistikách sú dostupné v akejkoľvek verzii klienta ("hrubý" klient na C#, webový klient na Flex a webový klient na HTML5). V týchto článkoch budeme používať snímky obrazovky z C# klienta, len preto, že vyzerajú lepšie v miniatúre:)
- ESXTOP – nástroj, ktorý sa spúšťa z príkazového riadku ESXi. S jeho pomocou môžete získať hodnoty výkonových štatistík v reálnom čase alebo exportovať tieto hodnoty za určitý čas do .csv súboru na ďalšiu analýzu. Následne poskytnem podrobnejšie informácie o tomto nástroji a prinesiem niekoľko užitočných odkazov na dokumentáciu a články na tému.
Trochu teórie
V ESXi má každý vCPU (jadro virtuálneho stroja) pridelený samostatný proces – svet v terminológii VMware. Existujú tiež pomocné procesy, ale z hľadiska analýzy výkonu VM sú menej zaujímavé.
Proces v ESXi môže byť v jednom z štyroch stavov:
- Spustiť – proces vykonáva nejakú užitočnú prácu.
- Čakať – proces nevykonáva žiadnu prácu (nečinný) alebo čaká na vstup/výstup.
- Náklady – stav, ktorý vzniká v viacerých jadrových virtuálnych strojoch. Vzniká, keď plánovač CPU hypervízora (ESXi CPU Scheduler) nemôže naplánovať súčasné vykonávanie na fyzických jadrách servera všetkých aktívnych jadier virtuálneho stroja. V reálnom svete všetky jadrá procesora pracujú paralelne, hostiteľský OS vo VM počíta s podobným správaním, preto musí hypervízor spomaliť jadrá VM, ktoré majú možnosť dokončiť cyklus rýchlejšie. V moderných verziách ESXi používajú plánovače CPU mechanizmus nazývaný relaxed co-scheduling: hypervízor berie do úvahy odchýlku medzi najrýchlejším a najpomalším jadrom virtuálneho stroja (skew). Ak odchýlka presahuje stanovený prah, "rýchle" jadro prechádza do stavu costop. Ak jadrá VM trávia veľa času v tomto stave, môže to spôsobiť problémy s výkonom.
- Pripravené – proces prechádza do tohto stavu, keď hypervízor nemá možnosť priradiť zdroje na jeho vykonanie. Vysoké hodnoty ready môžu spôsobiť problémy s výkonom VM.
Hlavné ukazovatele výkonu CPU virtuálneho stroja
Využitie CPU, %. Zobrazuje percento využitia CPU za stanovené obdobie.
Ako analyzovať? Ak VM stabilne využíva CPU na 90 % alebo sú výkyvy až do 100 %, máme problém. Problémy sa nemusia prejavovať len v "pomaly" fungovaní aplikácie vo VM, ale aj v nedostupnosti VM cez sieť. Ak monitorovací systém ukazuje, že VM občas vypadáva, venujte pozornosť výkyvom na grafe CPU Usage.
Existuje štandardný Alarm, ktorý zobrazuje zaťaženie CPU virtuálneho stroja:
Čo robiť? Ak CPU Usage vo VM neustále presahuje normu, môžete zvážiť zvýšenie počtu vCPU (bohužiaľ, to nie vždy pomôže) alebo presunúť VM na server s výkonnejšími procesormi.
Využitie CPU v MHz
Na grafoch v vCenter Usage v % môžete pozerať len celkový pre celý virtuálny stroj, grafy podľa jednotlivých jadier nie sú dostupné (v Esxtop sú hodnoty v % podľa jadier). Pre každé jadro si môžete pozrieť Využitie v MHz.
Ako analyzovať? Niekedy sa stáva, že aplikácia nie je optimalizovaná pre viacjadrovú architektúru: využíva na 100 % iba jedno jadro, zatiaľ čo ostatné zostávajú nevyťažené. Napríklad pri predvolených nastaveniach zálohovania MS SQL spúšťa proces iba na jednom jadre. Výsledkom je, že zálohovanie spomaľuje nie kvôli pomalej rýchlosti diskov (na čo sa pôvodne sťažoval používateľ), ale preto, že procesor to nezvláda. Problém bol vyriešený zmenou parametrov: zálohovanie začalo prebiehať paralelne do niekoľkých súborov (príslušne do niekoľkých procesov).
Príklad nerovnomerného zaťaženia jadier.
Taktiež sa môže vyskytnúť situácia (ako na grafe vyššie), keď sú jadrá zaťažené nerovnomerne a na niektorých z nich sú vrcholy na 100 %. Tak ako pri zaťažení iba jedného jadra, alarm na CPU Usage sa neaktivuje (platí pre celú VM), ale problémy s výkonom budú.
Čo robiť? Ak softvér vo virtuálnej mašine zaťažuje jadrá nerovnomerne (využíva len jedno jadro alebo časť jadier), nemá zmysel zvyšovať ich počet. V takom prípade je lepšie presunúť VM na server s výkonnejšími procesormi.
Taktiež môžete skúsiť skontrolovať nastavenia energetickej účinnosti v BIOS servera. Mnohí administrátori aktivujú v BIOSe režim Vysoký výkon a týmto spôsobom vypínajú technológie energetickej úspory C-states a P-states. V moderných procesoroch Intel sa používa technológia Turbo Boost, ktorá zvyšuje frekvenciu jednotlivých jadier procesora na úkor ostatných jadier. Ale funguje to len pri aktivovaných technológiách energetickej úspory. Ak ich vypneme, procesor nedokáže znížiť energetickú spotrebu jadier, ktoré nie sú zaťažené.
VMware odporúča nevypínať technológie energetickej úspory na serveroch, ale vybrať režimy, ktoré maximálne odovzdajú kontrolu nad energetickou spotrebou hypervízoru. Pri tomto by ste mali v nastaveniach energetickej účinnosti hypervízora zvoliť Vysoký výkon.
Ak vo vašej infraštruktúre jednotlivé VM (alebo jadrá VM) vyžadujú zvýšenú frekvenciu CPU, správne nastavenie energetickej spotreby môže významne zlepšiť ich výkon.
CPU Ready (Pripravenosť)
Ak je jadro VM (vCPU) v stave Ready, nevykonáva žiadnu užitočnú prácu. Tento stav nastáva, keď hypervízor nenájde voľné fyzické jadro, na ktoré by mohol priradiť proces vCPU virtuálnej stroje.
Ako analyzovať? Ak sú jadra virtuálnej stroje v stave Ready viac ako 10% času, pravdepodobne si všimnete problémy s výkonom. Jednoducho povedané, viac ako 10% času VM čaká na dostupnosť fyzických zdrojov.
V vCenter môžete vidieť 2 počítadlá súvisiace s CPU Ready:
- Readiness,
- Ready.
Hodnoty oboch počítadiel je možné zobraziť ako pre celú VM, tak aj pre jednotlivé jadrá.
Readiness ukazuje hodnotu ihneď v percentách, ale iba v reálnom čase (dáta za poslednú hodinu, interval merania 20 sekúnd). Toto počítadlo je najlepšie používať len pre okamžité hľadanie problémov.
Hodnoty počítadla Ready je tiež možné vidieť v historickej perspektíve. To je užitočné pre zistenie vzorov a pre hlbšiu analýzu problému. Napríklad, ak virtuálna stroj má problémy s výkonom v určitom čase, môžeme porovnať intervaly zvýšených hodnôt CPU Ready s celkovou záťažou na serveri, na ktorom daná VM beží, a prijať opatrenia na zníženie záťaže (ak DRS nezvládol).
Ready na rozdiel od Readiness nie je zobrazovaný v percentách, ale v milisekundách. Toto počítadlo typu Summation zobrazuje, koľko času počas meracieho obdobia jadro VM strávilo v stave Ready. Tento údaj môžeme previesť na percentá pomocou jednoduchej formulácie:
(CPU ready summation value / (default update interval grafu v sekundách * 1000)) * 100 = CPU ready %
Napríklad pre VM na grafe nižšie dosiahneme vrcholovú hodnotu Ready pre celú virtuálnu stroj nasledovne:
Pri výpočte hodnoty Ready v percentách je potrebné venovať pozornosť dvom aspektom:
- Hodnota Ready pre celú VM je súčtom Ready pre jadrá.
- Interval merania. Pre Reálny čas – je to 20 sekúnd, a napríklad na dennej grafike – to je 300 sekúnd.
Pri aktívnom riešení problémov je ľahké tieto jednoduché aspekty prehliadnuť a stratiť cenný čas na riešenie neexistujúcich problémov.
Vypočítame Ready na základe údajov z grafu nižšie. (324474/(20*1000))*100 = 1622% pre celý VM. Ak sa pozrieme na jadrá, vyzerá to menej zle: 1622/64 = 25% na jadro. V tomto prípade je odhalenie nástrahy celkom jednoduché: hodnota Ready je nerealistická. Ale ak hovoríme o 10–20% pre celý VM s viacerými jadrami, môže byť hodnota na každé jadro v normálnych medziach.
Čo robiť? Vysoká hodnota Ready naznačuje, že serveru chýbajú procesorové zdroje na normálnu prevádzku virtuálnych strojov. V tejto situácii zostáva len znížiť prebytok procesora (vCPU:pCPU). Je jasné, že to možno dosiahnuť znížením parametrov existujúcich VM alebo presunom niektorých VM na iné servery.
Co-stop
Ako analyzovať? Tento čítač má taktiež typ Summation a prepočítava sa na percentá podobne ako Ready:
(CPU co-stop summation value / (chart default update interval in seconds * 1000)) * 100 = CPU co-stop %
Tu je tiež potrebné venovať pozornosť počtu jadier na VM a intervalu merania.
V stave co-stop jadro nevykonáva užitočnú prácu. Pri správnom výbere veľkosti VM a normálnom zaťažení servera by mal byť čítač so-stop blízko nuly.
V tomto prípade je zaťaženie zjavne abnormálne :)
Čo robiť? Ak na jednom hypervízore pracuje niekoľko VM s veľkým počtom jadier a existuje prebytok CPU, potom môže čítač co-stop narásť, čo povedie k problémom s výkonom týchto VM.
Co-stop sa taktiež zvýši, ak sa pre aktívne jadrá jednej VM používajú vlákna na jednom fyzickom jadre servera so zapnutým hyper-threadingom. Takáto situácia môže nastať, ak má VM viac jadier, než je fyzicky dostupných na serveri, kde beží, alebo ak je pre VM zapnuté nastavenie 'preferHT'. O tomto nastavení si môžete prečítať .
Aby ste predišli problémom s výkonom VM z dôvodu vysokého co-stop, vyberajte veľkosť VM v súlade s odporúčaniami výrobcu softvéru, ktorý funguje na tejto VM, a s možnostami fyzického servera, kde VM beží.
Nerobte rezervné jadra, môže to spôsobiť problémy s výkonom nielen samotnej VM, ale aj jej susedov na serveri.
Ďalšie užitočné metriky CPU
Spustiť – koľko času (ms) počas meranej doby bol vCPU v stave RUN, teda fakticky vykonával užitočnú prácu.
Idle – koľko času (ms) bol vCPU počas merania v stave nečinnosti. Vysoké hodnoty Idle nie sú problém, len malo vCPU "nič robiť".
Čakať – koľko času (ms) bol vCPU počas merania v stave Wait. Keďže tento čítač obsahuje IDLE, vysoké hodnoty Wait tiež neznamenajú problémy. Ak je však vysoké Wait a IDLE je nízke, znamená to, že VM čakala na dokončenie operácií vstupu/výstupu, čo môže naznačovať problémy so výkonom pevného disku alebo iných virtuálnych zariadení VM.
Maximálne obmedzené – koľko času (ms) bol vCPU počas merania v stave Ready kvôli nastavenému limitu pre zdroje. Ak je výkon nepochopiteľne nízky, je užitočné skontrolovať hodnotu tohto čítača a limit CPU v nastaveniach VM. VM môžu mať nastavené limity, o ktorých neviete. Napríklad sa to stane, keď bola VM sklonovaná z šablóny, na ktorej bol nastavený limit CPU.
Čakanie na swap – koľko času vCPU čakalo na operácie s VMkernel Swap počas merania. Ak sú hodnoty tohto čítača vyššie ako nula, VM má určite problémy s výkonom. Podrobnejšie o SWAP sa budeme baviť v článku o čítačoch pamäte.
ESXTOP
Ak sú výkonnostné čítače v vCenter dobré na analýzu historických údajov, operatívna analýza problémov je lepšie vykonávať v ESXTOP. Tu sú všetky hodnoty zobrazené pripravené (nie je potrebné nič prevádzať) a minimálny merací interval je 2 sekundy.
Obrazovka ESXTOP pre CPU sa vyvoláva stlačením klávesy „c“ a vyzerá takto:
Pre pohodlie môžete zanechať iba procesy virtuálnych strojov stlačením Shift-V.
Aby ste si mohli pozrieť metriky pre jednotlivé jadrá VM, stlačte „e“ a zadajte GID zaujímavého VM (30919 na snímke obrazovky nižšie):
Krátko prejdeme cez stĺpce, ktoré sú predvolené. Ďalšie stĺpce môžete pridať stlačením „f“.
NWLD (Počet svetov) – počet procesov v skupine. Aby ste rozbalili skupinu a videli metriky pre každý proces (napríklad pre každé jadro viacjadrovej VM), stlačte „e“. Ak je v skupine viac ako jeden proces, hodnoty metrík pre skupinu sú rovné súčtu metrík pre jednotlivé procesy.
%POUŽITÉ – koľko cyklov CPU server využíva proces alebo skupina procesov.
%PREVÁDZKA – koľko času bol proces počas meraného obdobia v stave RUN, t.j. vykonával užitočnú prácu. Rozdiel od %USED spočíva v tom, že nezohľadňuje hyper-threading, frekvenčné škálovanie a čas strávený na systémových úlohách (%SYS).
%SYS – čas strávený na systémových úlohách, napríklad: spracovanie prerušenia, vstup/výstup, práca so sieťou atď. Hodnota môže byť vysoká, ak má VM vysoký vstup/výstup.
%OVRLP – koľko času fyzické jadro, na ktorom sa proces VM vykonáva, strávilo na úlohách iných procesov.
Tieto metriky sú vzájomne prepojené nasledujúcim spôsobom:
%USED = %RUN + %SYS – %OVRLP.
Zvyčajne je metrika %USED informatívnejšia.
%WAIT – koľko času bol proces počas meraného obdobia v stave Wait. Zohľadňuje IDLE.
%IDLE – koľko času bol proces počas meraného obdobia v stave IDLE.
%SWPWT – koľko času bol proces v priebehu merania vCPU v čakaní na operáciu so VMkernel Swap.
%VMWAIT – koľko času bol vCPU počas meraného obdobia v stave čakania na udalosť (zvyčajne vstup/výstup). Neexistuje ekvivalentný čítač v vCenter. Vysoké hodnoty naznačujú problémy s vstupom/výstupom na VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Ak VM nepoužíva VMkernel Swap, je pri analýze problémov s výkonnosťou rozumné pozerať sa na %VMWAIT, pretože táto metrika nezohľadňuje čas, keď VM nič nerobila (%IDLE).
%RDY – koľko času bol proces počas meraného obdobia v stave Ready.
%CSTP – koľko času bol proces počas meraného obdobia v stave costop.
%MLMTD – koľko času bol vCPU počas meraného obdobia v stave Ready z dôvodu nastaveného limitu na zdroje.
%WAIT + %RDY + %CSTP + %RUN = 100% – jadro VM je stále v jednom z týchto štyroch stavov.
CPU na hypervízore
V vCenter sú tiež dostupné úrovne výkonu CPU pre hypervízor, ale nezohľadňujú nič zaujímavé – je to len súčet čítačov zo všetkých VM na serveri.
Najpríjemnejšie je pozerať stav CPU na serveri na záložke Prehľad:
Pre server, rovnako ako pre virtuálny stroj, existuje štandardná výstraha:
Pri vysokom zaťažení CPU servera sa VM, ktoré na ňom pracujú, stretávajú s problémami s výkonnosťou.
V ESXTOP sú údaje o zaťažení CPU servera zobrazené v hornej časti obrazovky. Okrem štandardného zaťaženia CPU, ktoré je pre hypervízory marginálne informativne, sú tu ešte tri metriky:
CORE UTIL(%) – zaťaženie jadra fyzického servera. Táto metrika ukazuje, koľko času počas meracieho obdobia jadro vykonávalo prácu.
PCPU UTIL(%) – ak je aktivovaný hyper-threading, na každé fyzické jadro pripadnú dva vlákna (PCPU). Táto metrika ukazuje, koľko času každé vlákno vykonávalo prácu.
PCPU USED(%) – to isté ako PCPU UTIL(%), ale berie do úvahy frekvenčné škálovanie (buď zníženie frekvencie jadra za účelom úspory energie, alebo zvýšenie frekvencie jadra technológiou Turbo Boost) a hyper-threading.
PCPU_USED% = PCPU_UTIL% * efektívna frekvencia jadra / nominálna frekvencia jadra.
Na tomto snímku obrazovky pre niektoré jadrá je z dôvodu fungovania Turbo Boost hodnota USED vyššia ako 100%, pretože frekvencia jadra je nad nominálnou.
Pár slov o tom, ako sa zohľadňuje hyper-threading. Ak procesy bežia 100% času na oboch vláknach fyzického jadra servera a jadro pracuje na nominálnej frekvencii, tak:
- CORE UTIL pre jadro bude 100%,
- PCPU UTIL pre obe vlákna bude 100%,
- PCPU USED pre obe vlákna bude 50%.
Ak oba vlákna nefungovali 100% času počas meracieho obdobia, v tých obdobiach, keď vlákna pracovali paralelne, sa PCPU USED pre jadrá delí na polovicu.
V ESXTOP je tiež obrazovka s parametrami spotreby energie CPU servera. Tu si môžete skontrolovať, či server používa technológie na úsporu energie: C-states a P-states. Aktivuje sa klávesom „p“:
Štandardné problémy s výkonom CPU
Na záver sa pozriem na typické príčiny problémov s výkonom CPU VM a poskytnem krátke rady na ich riešenie:
Nedostatok taktných frekvencií jadra. Ak nie je možné preniesť VM na výkonnejšie jadrá, môžete sa pokúsiť zmeniť nastavenia energetickej spotreby, aby Turbo Boost fungoval efektívnejšie.
Nesprávne sizing VM (príliš veľa/málo jadier). Ak nastavíte málo jadier, nastane vysoké zaťaženie CPU VM. Ak ich je veľa, zachytíte vysoké co-stop.
Veľká preplatba CPU na serveri. Ak má VM vysoký Ready, znížte preplatbu CPU.
Nesprávna NUMA topológia na veľkých VM. TOPOLÓGIA NUMA, ktorú vidí VM (vNUMA), musí zodpovedať TOPOLÓGII NUMA servera (pNUMA). O diagnostike a možných riešeniach tohto problému sa píše napríklad v knihe . Ak sa nechcete hlboko zaoberať a nemáte licenčné obmedzenia pre OS nainštalovaný na VM, vytvorte na VM veľa virtuálnych soketov s jednou jadrom. Mnoho ste nestratili 🙂
Toto je všetko o CPU. Klásť otázky. V nasledujúcej časti poviem o operačnej pamäti.
Užitočné odkazy
Zdroj: habr.com
