Pokud spravujete virtuální infrastrukturu založenou na VMware vSphere (nebo na jakémkoli jiném technologickém stacku), pravděpodobně často slyšíte stížnosti uživatelů: „Virtuální stroj je pomalý!“ V této sérii článků analyzuji metriky výkonu a řeknu vám, co a proč se zpomaluje a jak se ujistit, že se nezpomaluje.
Budu zvažovat následující aspekty výkonu virtuálního stroje:
- CPU,
- RAM,
- DISK,
- Síť.
Začnu CPU.
K analýze výkonu budeme potřebovat:
- Čítače výkonu vCenter – čítače výkonu, jejichž grafy lze prohlížet prostřednictvím klienta vSphere Client. Informace o těchto počítadlech jsou dostupné v jakékoli verzi klienta („tlustý“ klient v C#, webový klient ve Flex a webový klient v HTML5). V těchto článcích použijeme screenshoty z C# klienta, jen proto, že vypadají lépe v miniatuře :)
- ESXTOP – nástroj, který se spouští z příkazového řádku ESXi. S jeho pomocí můžete získat hodnoty čítačů výkonu v reálném čase nebo tyto hodnoty nahrát za určité období do souboru .csv pro další analýzu. Dále vám řeknu více o tomto nástroji a poskytnu několik užitečných odkazů na dokumentaci a články na toto téma.
Některé teorie
V ESXi je za provoz každého vCPU (virtual machine core) zodpovědný samostatný proces – svět v terminologii VMware. Existují také servisní procesy, ale z hlediska analýzy výkonu VM jsou méně zajímavé.
Proces v ESXi může být v jednom ze čtyř stavů:
- Běh – proces vykonává nějakou užitečnou práci.
- Počkejte – proces nepracuje (nečiní) nebo čeká na vstup/výstup.
- Costop – stav, který se vyskytuje u vícejádrových virtuálních počítačů. Dochází k tomu, když plánovač CPU hypervisoru (ESXi CPU Scheduler) nemůže naplánovat současné spuštění všech aktivních jader virtuálních strojů na jádrech fyzického serveru. Ve fyzickém světě pracují všechna jádra procesoru paralelně, hostující OS uvnitř VM očekává podobné chování, takže hypervizor musí zpomalit jádra VM, která mají schopnost dokončit svůj takt rychleji. V moderních verzích ESXi používá plánovač CPU mechanismus nazývaný uvolněné společné plánování: hypervizor zvažuje mezeru mezi „nejrychlejším“ a „nejpomalejším“ jádrem virtuálního stroje (zešikmení). Pokud mezera překročí určitou prahovou hodnotu, rychlé jádro přejde do stavu costop. Pokud jádra virtuálních počítačů tráví v tomto stavu hodně času, může to způsobit problémy s výkonem.
- Připravený – proces vstoupí do tohoto stavu, když hypervizor není schopen alokovat zdroje pro jeho provedení. Vysoké hodnoty připravenosti mohou způsobit problémy s výkonem virtuálního počítače.
Základní čítače výkonu CPU virtuálního stroje
Využití procesoru, %. Zobrazuje procento využití CPU za dané období.
Jak analyzovat? Pokud virtuální počítač trvale využívá CPU na 90 % nebo jsou špičky až 100 %, pak máme problémy. Problémy mohou být vyjádřeny nejen v „pomalém“ provozu aplikace uvnitř VM, ale také v nedostupnosti VM přes síť. Pokud monitorovací systém ukazuje, že virtuální počítač pravidelně vypadává, věnujte pozornost vrcholům v grafu využití CPU.
Existuje standardní alarm, který ukazuje zatížení CPU virtuálního počítače:
Co dělat? Pokud využití CPU virtuálního počítače neustále překračuje střechu, můžete přemýšlet o zvýšení počtu vCPU (bohužel to vždy nepomůže) nebo o přesunutí virtuálního počítače na server s výkonnějšími procesory.
Využití CPU v MHz
V grafech využití vCenter v % vidíte pouze pro celý virtuální stroj, pro jednotlivá jádra nejsou žádné grafy (v Esxtopu jsou hodnoty % pro jádra). U každého jádra vidíte využití v MHz.
Jak analyzovat? Stává se, že aplikace není optimalizována pro vícejádrovou architekturu: využívá pouze jedno jádro na 100 % a zbytek je nečinný bez zátěže. Například s výchozím nastavením zálohování spustí MS SQL proces pouze na jednom jádru. V důsledku toho se zálohování zpomaluje ne kvůli pomalé rychlosti disků (na tu si uživatel zpočátku stěžoval), ale kvůli tomu, že si procesor neví rady. Problém byl vyřešen změnou parametrů: zálohování začalo probíhat paralelně v několika souborech (respektive v několika procesech).
Příklad nerovnoměrného zatížení jader.
Dochází také k situaci (jako na grafu výše), kdy jsou jádra zatěžována nerovnoměrně a některá mají špičky 100 %. Stejně jako při načítání pouze jednoho jádra nebude fungovat alarm pro využití CPU (je pro celý VM), ale budou problémy s výkonem.
Co dělat? Pokud software ve virtuálním stroji zatěžuje jádra nerovnoměrně (využívá pouze jedno jádro nebo část jader), nemá smysl jejich počet zvyšovat. V tomto případě je lepší přesunout VM na server s výkonnějšími procesory.
Můžete také zkusit zkontrolovat nastavení spotřeby energie v systému BIOS serveru. Mnoho správců povoluje v systému BIOS režim vysokého výkonu a tím deaktivuje technologie úspory energie stavů C a P. Moderní procesory Intel využívají technologii Turbo Boost, která zvyšuje frekvenci jednotlivých jader procesoru na úkor jader ostatních. Funguje to ale pouze tehdy, když jsou zapnuty technologie pro úsporu energie. Pokud je zakážeme, procesor nedokáže snížit spotřebu jader, která nejsou zatížena.
Společnost VMware doporučuje nevypínat technologie pro úsporu energie na serverech, ale zvolit režimy, které ponechají správu napájení co nejvíce na hypervizoru. V tomto případě musíte v nastavení spotřeby energie hypervizoru vybrat Vysoký výkon.
Pokud máte ve své infrastruktuře jednotlivé virtuální počítače (nebo jádra virtuálních počítačů), které vyžadují zvýšenou frekvenci CPU, může správné nastavení spotřeby energie výrazně zlepšit jejich výkon.
CPU připraveno
Pokud je jádro virtuálního počítače (vCPU) ve stavu Připraveno, neprovádí užitečnou práci. Tento stav nastane, když hypervizor nenajde volné fyzické jádro, ke kterému lze přiřadit proces vCPU virtuálního stroje.
Jak analyzovat? Obvykle, pokud jsou jádra virtuálního počítače ve stavu Připraveno více než 10 % času, zaznamenáte problémy s výkonem. Jednoduše řečeno, více než 10 % času virtuální počítač čeká na zpřístupnění fyzických prostředků.
Ve vCenter můžete zobrazit 2 čítače související s CPU Ready:
- připravenost,
- Připraveno.
Hodnoty obou čítačů lze zobrazit jak pro celý VM, tak pro jednotlivá jádra.
Připravenost ukazuje hodnotu okamžitě v procentech, ale pouze v reálném čase (údaje za poslední hodinu, interval měření 20 sekund). Toto počítadlo je lepší používat pouze k hledání problémů „v patách“.
Na hodnoty připravených počítadel lze také nahlížet z historické perspektivy. To je užitečné pro stanovení vzorců a pro hlubší analýzu problému. Pokud například virtuální počítač začne mít v určitou dobu problémy s výkonem, můžete porovnat intervaly hodnoty CPU Ready s celkovým zatížením serveru, kde je tento virtuální počítač spuštěn, a přijmout opatření ke snížení zatížení (pokud DRS selže).
Ready, na rozdíl od Readiness, se nezobrazuje v procentech, ale v milisekundách. Toto je čítač typu Summation, to znamená, že ukazuje, jak dlouho během doby měření bylo jádro virtuálního počítače ve stavu Připraveno. Tuto hodnotu můžete převést na procenta pomocí jednoduchého vzorce:
(hodnota součtu připravenosti CPU / (výchozí interval aktualizace grafu v sekundách * 1000)) * 100 = připravenost CPU %
Například pro virtuální počítač v níže uvedeném grafu bude maximální hodnota Ready pro celý virtuální počítač následující:
Při výpočtu procenta připravenosti byste měli věnovat pozornost dvěma bodům:
- Hodnota Ready pro celý virtuální počítač je součtem Ready napříč jádry.
- Interval měření. U reálného času je to 20 sekund a například v denních grafech je to 300 sekund.
Díky aktivnímu řešení problémů lze tyto jednoduché body snadno přehlédnout a drahocenný čas ztrácet na řešení neexistujících problémů.
Pojďme vypočítat Ready na základě údajů z grafu níže. (324474/(20*1000))*100 = 1622 % pro celý virtuální počítač. Když se podíváte na jádra, není to tak děsivé: 1622/64 = 25 % na jádro. V tomto případě je úlovek poměrně snadno rozpoznatelný: hodnota Ready je nerealistická. Ale pokud mluvíme o 10–20 % pro celý VM s několika jádry, pak pro každé jádro může být hodnota v normálním rozsahu.
Co dělat? Vysoká hodnota Připraveno znamená, že server nemá dostatek procesorových prostředků pro normální provoz virtuálních strojů. V takové situaci zbývá jen snížit přetížení procesorem (vCPU:pCPU). Toho lze samozřejmě dosáhnout snížením parametrů stávajících virtuálních počítačů nebo migrací části virtuálních počítačů na jiné servery.
Společné zastavení
Jak analyzovat? Toto počítadlo je také typu Summation a je převedeno na procenta stejným způsobem jako Ready:
(hodnota součtu co-stop CPU / (výchozí interval aktualizace grafu v sekundách * 1000)) * 100 = CPU co-stop %
Zde je také potřeba dávat pozor na počet jader na VM a interval měření.
Ve stavu costop jádro nevykonává užitečnou práci. Při správném výběru velikosti virtuálního počítače a normálního zatížení serveru by měl být čítač co-stop blízko nule.
V tomto případě je zátěž zjevně abnormální :)
Co dělat? Pokud na jednom hypervizoru běží několik virtuálních počítačů s velkým počtem jader a na CPU je nadměrné předplatné, může se zvýšit čítač co-stop, což povede k problémům s výkonem těchto virtuálních počítačů.
Co-stop se také zvýší, pokud aktivní jádra jednoho virtuálního počítače používají vlákna na jednom jádru fyzického serveru s povoleným hyper-treadingem. Tato situace může nastat například, pokud má virtuální počítač více jader, než je fyzicky dostupných na serveru, kde běží, nebo pokud je pro virtuální počítač povoleno nastavení „preferHT“. O tomto nastavení si můžete přečíst .
Chcete-li se vyhnout problémům s výkonem virtuálního počítače kvůli vysokému co-stop, vyberte velikost virtuálního počítače v souladu s doporučeními výrobce softwaru, který běží na tomto virtuálním počítači, a možnostmi fyzického serveru, na kterém virtuální počítač běží.
Nepřidávejte jádra do rezervy; to může způsobit problémy s výkonem nejen pro samotný VM, ale také pro jeho sousedy na serveru.
Další užitečné metriky CPU
Běh – kolik času (ms) během doby měření bylo vCPU ve stavu RUN, to znamená, že skutečně vykonávalo užitečnou práci.
Líný – jak dlouho (ms) během doby měření byl vCPU ve stavu nečinnosti. Vysoké hodnoty Idle nejsou problém, vCPU prostě neměl „co dělat“.
Počkejte – jak dlouho (ms) během doby měření byl vCPU ve stavu čekání. Vzhledem k tomu, že tento čítač obsahuje IDLE, vysoké hodnoty Wait také neindikují problém. Pokud je však Wait IDLE nízká, zatímco Wait je vysoká, znamená to, že virtuální počítač čekal na dokončení I/O operací, a to zase může znamenat problém s výkonem pevného disku nebo jakýchkoli virtuálních zařízení virtuálního počítače.
Max omezený – jak dlouho (ms) během doby měření bylo vCPU ve stavu Připraveno kvůli nastavenému limitu zdrojů. Pokud je výkon nevysvětlitelně nízký, pak je užitečné zkontrolovat hodnotu tohoto čítače a limit CPU v nastavení VM. Virtuální počítače mohou mít skutečně limity, o kterých nevíte. K tomu například dochází, když byl virtuální počítač klonován ze šablony, na které byl nastaven limit CPU.
Vyměňte čekání – jak dlouho během doby měření čekal vCPU na operaci s VMkernel Swap. Pokud jsou hodnoty tohoto čítače nad nulou, pak má VM určitě problémy s výkonem. Více si o SWAP povíme v článku o počítadlech RAM.
ESXTOP
Pokud jsou čítače výkonu ve vCenter dobré pro analýzu historických dat, je lepší provést provozní analýzu problému v ESXTOP. Zde jsou všechny hodnoty prezentovány v hotové podobě (není třeba nic překládat) a minimální doba měření je 2 sekundy.
Obrazovka ESXTOP pro CPU se vyvolá klávesou „c“ a vypadá takto:
Pro usnadnění můžete stisknutím Shift-V opustit pouze procesy virtuálního stroje.
Chcete-li zobrazit metriky pro jednotlivá jádra virtuálních počítačů, stiskněte „e“ a zadejte GID požadovaného virtuálního počítače (30919 na snímku obrazovky níže):
Dovolte mi krátce projít sloupce, které jsou standardně prezentovány. Další sloupce lze přidat stisknutím "f".
NWLD (Počet světů) – počet procesů ve skupině. Chcete-li rozbalit skupinu a zobrazit metriky pro každý proces (například pro každé jádro ve vícejádrovém virtuálním počítači), stiskněte „e“. Pokud je ve skupině více než jeden proces, pak se hodnoty metrik pro skupinu rovnají součtu metrik pro jednotlivé procesy.
%POUŽITÝ – kolik cyklů CPU serveru používá proces nebo skupina procesů.
%BĚH – jak dlouho během doby měření byl proces ve stavu RUN, tzn. udělal užitečnou práci. Od %USED se liší tím, že nebere v úvahu hyper-threading, frekvenční škálování a čas strávený na systémových úlohách (%SYS).
%SYS – čas strávený na systémových úlohách, například: zpracování přerušení, I/O, síťový provoz atd. Hodnota může být vysoká, pokud má VM velký I/O.
%OVRLP – kolik času fyzické jádro, na kterém běží proces VM, strávilo úkoly jiných procesů.
Tyto metriky spolu souvisí následovně:
%USED = %RUN + %SYS - %OVRLP.
Metrika %USED je obvykle informativnější.
%POČKEJTE – jak dlouho během doby měření byl proces ve stavu čekání. Umožňuje IDLE.
%LÍNÝ – jak dlouho během doby měření byl proces v klidovém stavu.
%SWPWT – jak dlouho během doby měření čekal vCPU na operaci s VMkernel Swap.
%VMWAIT – jak dlouho během doby měření bylo vCPU ve stavu čekání na událost (obvykle I/O). Ve vCenter žádné podobné počítadlo není. Vysoké hodnoty indikují problémy s I/O na VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Pokud virtuální počítač nepoužívá VMkernel Swap, pak se při analýze problémů s výkonem doporučuje podívat se na %VMWAIT, protože tato metrika nebere v úvahu dobu, kdy virtuální počítač nic nedělal (%IDLE).
% RDY – jak dlouho během doby měření byl proces ve stavu Připraveno.
%CSTP – jak dlouho během doby měření byl proces ve stavu costop.
%MLMTD – jak dlouho během doby měření bylo vCPU ve stavu Připraveno kvůli nastavenému limitu zdrojů.
%WAIT + %RDY + %CSTP + %RUN = 100 % – jádro VM je vždy v jednom z těchto čtyř stavů.
CPU na hypervisoru
vCenter má také čítače výkonu CPU pro hypervizor, ale nejsou ničím zajímavým - jsou prostě součtem čítačů pro všechny virtuální počítače na serveru.
Nejpohodlnější způsob, jak zobrazit stav CPU na serveru, je na kartě Souhrn:
Pro server, stejně jako pro virtuální stroj, existuje standardní Alarm:
Když je zatížení procesoru serveru vysoké, virtuální počítače na něm běžící začnou mít problémy s výkonem.
V ESXTOP se v horní části obrazovky zobrazují údaje o zatížení CPU serveru. Kromě standardního zatížení procesoru, které není pro hypervizory příliš vypovídající, existují další tři metriky:
CORE UTIL (%) – zatížení fyzického jádra serveru. Tento čítač ukazuje, jak dlouho jádro pracovalo během doby měření.
PCPU UTIL (%) – pokud je povoleno hyper-threading, pak jsou na fyzické jádro dvě vlákna (PCPU). Tato metrika ukazuje, jak dlouho každému vláknu trvalo dokončení práce.
POUŽITÉ PCPU (%) – stejně jako PCPU UTIL(%), ale zohledňuje frekvenční škálování (buď snížení frekvence jádra pro účely úspory energie, nebo zvýšení frekvence jádra díky technologii Turbo Boost) a hyper-threading.
PCPU_USED% = PCPU_UTIL% * efektivní frekvence jádra / jmenovitá frekvence jádra.
Na tomto snímku obrazovky je u některých jader v důsledku Turbo Boost hodnota USED větší než 100 %, protože frekvence jádra je vyšší než nominální.
Pár slov o tom, jak se hyper-threading bere v úvahu. Pokud jsou procesy prováděny 100 % času na obou vláknech fyzického jádra serveru, zatímco jádro pracuje na nominální frekvenci, pak:
- CORE UTIL pro jádro bude 100 %,
- PCPU UTIL pro obě vlákna bude 100 %,
- POUŽITÝ PCPU pro obě vlákna bude 50 %.
Pokud obě vlákna nefungovala 100% času během období měření, pak během těch období, kdy vlákna fungovala paralelně, se PCPU POUŽÍVANÉ pro jádra rozdělí na polovinu.
ESXTOP má také obrazovku s parametry spotřeby CPU serveru. Zde můžete vidět, zda server používá energeticky úsporné technologie: C-stavy a P-stavy. Vyvoláno klávesou "p":
Běžné problémy s výkonem CPU
Nakonec se podívám na typické příčiny problémů s výkonem CPU VM a poskytnu krátké tipy pro jejich řešení:
Takt jádra nestačí. Pokud není možné upgradovat váš VM na výkonnější jádra, můžete zkusit změnit nastavení napájení, aby Turbo Boost fungoval efektivněji.
Nesprávná velikost virtuálního počítače (příliš mnoho/málo jader). Pokud nainstalujete málo jader, bude na VM velké zatížení CPU. Pokud je toho hodně, chyťte vysokou spoluzastávku.
Velké nadměrné předplatné CPU na serveru. Pokud má virtuální počítač vysokou připravenost, snižte nadměrné odběry CPU.
Nesprávná topologie NUMA na velkých virtuálních počítačích. Topologie NUMA viděná virtuálním počítačem (vNUMA) musí odpovídat topologii NUMA serveru (pNUMA). Diagnostika a možná řešení tohoto problému jsou napsány např. v knize . Pokud nechcete jít hlouběji a nemáte licenční omezení pro operační systém nainstalovaný na virtuálním počítači, vytvořte na virtuálním počítači mnoho virtuálních soketů, jedno jádro po druhém. Moc neztratíš :)
To je pro mě o CPU vše. Klást otázky. V další části budu mluvit o RAM.
Užitečné odkazy
Zdroj: www.habr.com