CPU Ready je vec, ktorú možno nepoznáte. Na prvý dojem to môže znieť ako dobrá vec, ale bohužiaľ to tak nie je. CPU Ready trápi virtuálne prostredia dlhšie, ako sme vedeli, o čo ide. VMware to definuje ako „Percento času, keď bol virtuálny stroj pripravený, ale nemohol naplánovať jeho spustenie na fyzickom CPU. Čas pohotovosti CPU závisí od počtu virtuálnych strojov na hostiteľovi a od ich zaťaženia CPU. “ Hyper-V iba nedávno začal poskytovať toto počítadlo (Hyper-V Hypervisor Virtuálny procesor CPU, doba čakania na odoslanie) a ďalšie hypervízory nemusia túto metriku stále poskytovať.
Aby sme pochopili, čo je CPU Ready, budeme musieť pochopiť, ako hypervízori plánujú virtuálne CPU (vCPU) na fyzické CPU (pCPU). Ak je na virtuálnom počítači potrebný čas vCPU, je potrebné naplánovať vCPU proti pCPU, aby sa príkazy / procesy / vlákna mohli spustiť proti pCPU. V ideálnom svete neexistujú žiadne konflikty zdrojov alebo úzke miesta, keď k tomu musí dôjsť. Keď potrebuje jeden vCPU VM naplánovať čas proti pCPU, je k dispozícii jadro pCPU a CPU Ready je v tomto ideálnom svete veľmi minimálna. Je dôležité si uvedomiť, že CPU Ready vždy existuje, ale v ideálnom svete je veľmi minimálny a nevšimnutý.
V skutočnom svete je jednou z výhod virtualizácie to, že sa môžete staviť, že mnohé z vašich virtuálnych počítačov nespustia všetky svoje vCPU súčasne a ak sú to virtuálne počítače s veľmi nízkym využitím, môžete dokonca odhadnúť, koľko môžete načítajte fyzického hostiteľa na základe využitia procesora a pamäte RAM. V minulosti boli vydané odporúčania mať pomer 4 vCPU k 1 pCPU alebo dokonca 10: 1 v závislosti od pracovnej záťaže. Môžete mať napríklad jeden štvorjadrový procesor, ale mať 4 virtuálne počítače s vCPU, ktoré vám poskytnú 16 vCPU až 4 pCPU alebo 4: 1. Inžinieri však začali vidieť, že prostredie bolo strašne pomalé a nedokázali zistiť prečo. Využitie RAM sa zdalo v poriadku, využitie CPU na fyzických hostiteľoch môže byť dokonca veľmi nízke, pod 20%. Latencia úložiska bola extrémne nízka, napriek tomu boli VM veľmi pomalé.
To, čo sa dialo v tomto scenári, bolo CPU Ready. Bola vytvorená fronta vCPU pripravenej na naplánovanie, ale nie je k dispozícii žiadna pCPU na naplánovanie. Hypervisor by zastavil plánovanie a spôsobil latenciu hosťujúceho VM. Je to tichý zabijak, ktorý až do posledných rokov nemal veľa nástrojov na detekciu. Vo virtuálnom počítači so systémom Windows by trvalo spustenie navždy a potom, keď to nakoniec urobí, keď kliknete na ponuku Štart, zobrazenie by trvalo navždy. Môžete na ňu dokonca znova kliknúť a myslieť si, že neakceptuje vaše prvé kliknutie. Keď sa to nakoniec vyrovná, zobrazí sa dvojité kliknutie. V systéme Linux sa môže váš VM naštartovať do režimu iba na čítanie alebo dokonca neskôr zmeniť súborové systémy na režim iba na čítanie.
Ako teda bojujeme s procesorom Ready? Existuje niekoľko spôsobov, ktoré môžu pomôcť. Prvým je sledovanie metrík pripravených na procesor. Vo VMware sa neodporúča ísť nad 10%, ale z vlastnej skúsenosti si používatelia začnú všímať viac ako 5 - 7% v závislosti od typu VM a od toho, čo beží.
Ďalej uvediem niekoľko príkladov z programu VMware ESXi 5.5 na ukážku CPU Ready. Pomocou príkazového riadku spustite program „esxtop“. Stlačením „c“ zobrazíte CPU a mal by sa zobraziť stĺpec „ % RDY ”Pre CPU Ready. Môžete stlačiť veľké písmeno “ V. ”Pre VM Only view.
Tu vidíte, že% RDY je do istej miery vysoký pre dosť nepoužívané prostredie. V tomto prípade je na mojom ESXi 5.5 spustený testovací VM nad VMware Fusion (Mac hypervisor), takže sa očakáva, že bude trochu na vyššej úrovni, pretože bežíme VM na hypervízore nad iným hypervízorom.
V klientovi vSphere môžete vytiahnuť konkrétny VM a kliknúť na kartu Výkon. Odtiaľ kliknite na „Možnosti grafu“
V časti Možnosti grafu vyberte položku CPU, Real-time (ak máte vCenter, môžete mať aj iné možnosti časovania ako v reálnom čase). Odtiaľ v počítadlách vyberte možnosť „Pripravené“. Možno budete musieť zrušiť výber iného počítadla, pretože zobrazenie v danom okamihu umožňuje iba dva typy údajov.
Všimnete si, že táto hodnota je súhrnom pripravenosti versus percento. Tu je odkaz na článok o VMware KB o tom, ako previesť súhrnné metriky na percento. - https://kb.vmware.com/kb/2002181
Pri nákupe hardvéru pomáha viac jadier zmierniť vplyv CPU Ready. Pomáha tiež hyperthreading. Aj keď Hyperthreading neposkytuje úplné druhé jadro pre každé primárne jadro, zvyčajne stačí povoliť plánovanie vCPU na pCPU a pomôcť tento problém zmierniť. Aj keď sa hypervízory začínajú posúvať od odporúčania pomeru vCPU k pCPU, v stredne využívanom prostredí s pomerom strán 4: 1 vám to zvyčajne pôjde dobre a odtiaľ pôjdete. Keď začnete načítať virtuálne počítače, pozrite sa na latenciu procesora, CPU Ready a celkový dojem a výkon. Ak máte nejaké veľmi náročné virtuálne počítače, možno ich budete chcieť rozdeliť do iných klastrov a použiť nižší pomer a udržiavať ich ľahkú. Na druhej strane pre VM, kde výkon nie je kľúčový a je v poriadku, že bežia pomaly, sa môžete prihlásiť na odber oveľa vyššie.
Vhodná veľkosť VM je tiež obrovským nástrojom v boji proti CPU Ready. Mnoho predajcov dobre odporúča technické parametre, ktoré by virtuálny počítač mohol skutočne potrebovať. Tradične viac CPU a viac jadier = viac energie. Problém vo virtuálnom prostredí je, že hypervisor musí naplánovať všetky vCPU na pCPU približne v rovnakom čase a uzamknutie pCPU môže byť problematické. Ak máte 8 vCPU VM, musíte uzamknúť 8 pCPU, aby ste im umožnili plánovať súčasne. Ak váš vCPU VM v danom okamihu používa iba 10% celkových vCPU, je lepšie znížiť počet vCPU na 2 alebo 4. Je lepšie prevádzkovať VM na 50-80% CPU s menším vCPU ako 10% na viac vCPU. Tento problém je čiastočne spôsobený tým, že plánovač CPU operačného systému je navrhnutý tak, aby používal čo najviac jadier, zatiaľ čo pokiaľ by bol trénovaný na maximalizáciu jadier pred použitím väčšieho množstva, môže to znamenať menší problém. Predimenzovaný VM môže fungovať dobre, ale môže byť „hlučným susedom“ pre iné VM, takže je to zvyčajne proces, kedy musíte prejsť cez všetky VM v klastri, aby ste ich „správne dimenzovali“, aby ste videli nejaké zvýšenie výkonu.
Mnohokrát ste narazili na CPU Ready a je ťažké začať správne dimenzovať VM alebo upgradovať na procesory s viac jadrami. Ak sa nachádzate v tejto situácii, pridanie ďalších hostiteľov do vášho klastra vám môže pomôcť pri rozložení záťaže medzi ďalších hostiteľov. Ak máte hostiteľov s väčším počtom jadier / procesorov ako ostatní, môže pomôcť aj naviazanie virtuálnych počítačov s vysokou vCPU na týchto hostiteľov s vyšším jadrom. Chcete zaistiť, aby váš fyzický hostiteľ mal aspoň rovnaký počet jadier, ak nie väčší ako VM, inak bude veľmi pomalé / ťažké naplánovať prebytok vCPU na pCPU, pretože je potrebné ich uzamknúť zhruba v rovnakom čase .
Váš hypervízor môže nakoniec podporovať rezervácie a limity na virtuálnom počítači. Tieto práce sa niekedy stanú náhodne. Agresívne nastavenia týchto parametrov môžu spôsobiť, že procesor bude pripravený, aj keď v skutočnosti sú preň dostupné základné zdroje. Spravidla je najlepšie používať rezervy a limity striedmo a iba v nevyhnutných prípadoch. Správne veľký klaster väčšinou správne vyváži zdroje, ktoré zvyčajne nie sú potrebné.
Stručne povedané, najlepšou obranou proti CPU Ready je vedieť, že existuje a ako ju skontrolovať. Z vyššie uvedeného potom môžete systematicky určovať najlepšie kroky zmierňovania pre vaše prostredie. Informácie z tohto článku sa väčšinou vzťahujú všeobecne na akýkoľvek hypervízor, hoci snímky obrazovky a grafy sa vzťahujú špeciálne na VMware.
5 minút čítania
