Gata de procesor: ucigașul silențios pentru hipervizor

CPU Ready este ceva cu care s-ar putea să nu fiți familiarizați. La o primă impresie, poate suna ca un lucru bun, dar, din păcate, nu este. CPU Ready afectează mediile virtuale de mai mult timp decât știam ce este. VMware definește acest lucru ca „Procentul de timp în care mașina virtuală a fost gata, dar nu a putut fi programat să ruleze pe CPU fizic. Timpul de pregătire a procesorului depinde de numărul de mașini virtuale de pe gazdă și de încărcările lor de procesor. ” Hyper-V a început recent să furnizeze acest contor (procesor virtual Hyper-V Hypervisor CPU Wait time per dispatch) și este posibil ca și alți hipervizori să nu furnizeze această valoare.

Pentru a înțelege ce este CPU Ready, va trebui să înțelegem modul în care hipervizorii programează procesoare virtuale (vCPU) către procesoare fizice (pCPU). Când este nevoie de timpul vCPU într-o mașină virtuală, este necesar ca programele vCPU să fie programate în funcție de pCPU (s), astfel încât comenzile / procesele / firele să poată rula împotriva pCPU. Într-o lume ideală, nu există conflicte de resurse sau blocaje atunci când acest lucru trebuie să se întâmple. Când o singură mașină virtuală vCPU trebuie să programeze timpul în funcție de o pCPU, este disponibil un nucleu pCPU, iar CPU Ready este foarte minim în această lume ideală. Este important să rețineți că CPU Ready există întotdeauna, dar într-o lume ideală este foarte minimă și nu se observă.

În lumea reală, unul dintre avantajele virtualizării este că puteți paria că multe dintre VM-urile dvs. nu vor crește toate vCPU-urile lor în același timp și dacă sunt VM-uri cu utilizare foarte scăzută, puteți chiar să ghiciți cât de mult puteți încărcați-vă gazda fizică pe baza utilizării procesorului și a utilizării RAM. În trecut, au fost făcute recomandări pentru a avea un raport de 4 vCPU la 1 pCPU sau chiar un raport de 10: 1 în funcție de volumul de muncă. De exemplu, este posibil să aveți un singur procesor quad core, dar să aveți 4 VM-uri cu vCPU fiecare pentru a vă oferi 16 vCPU-uri la 4 pCPU-uri sau 4: 1. Totuși, ceea ce inginerii începeau să vadă este că mediile erau doar teribil de lente și nu își puteau da seama de ce. Utilizarea RAM părea bună, utilizarea procesorului pe gazdele fizice poate fi chiar foarte scăzută, sub 20%. Latența stocării a fost extrem de redusă, totuși VM-urile au fost extrem de lente.

Ceea ce se întâmpla în acest scenariu era CPU Ready. S-a construit o coadă a vCPU gata pentru a fi programată, dar nu există pCPU disponibil pentru a fi programat. Hipervizorul ar bloca programarea și ar provoca latență pentru VM invitat. Este un ucigaș tăcut că până în ultimii ani nu existau multe instrumente de detectat. Într-o mașină virtuală Windows, ar fi nevoie de o veșnicie pentru a porni și apoi, atunci când se face în sfârșit, când faceți clic pe meniul Start, ar dura o veșnicie pentru a apărea. Puteți chiar să faceți clic pe el din nou, crezând că nu a acceptat primul dvs. clic și, atunci când, în cele din urmă, va ajunge, veți primi un dublu clic. Pe Linux, VM-ul dvs. poate porni în modul numai citire sau chiar poate comuta sistemele de fișiere în modul numai citire la un moment dat mai târziu.

Deci, cum putem combate CPU Ready? Există câteva modalități care vă pot ajuta. Mai întâi este monitorizarea măsurătorilor CPU Ready. În VMware, nu se recomandă să depășească 10%, dar, din experiența personală, utilizatorii încep să observe mai mult de 5-7%, în funcție de tipul de VM și de ce rulează.

Mai jos voi folosi câteva exemple din VMware ESXi 5.5 pentru a afișa CPU Ready. Folosind linia de comandă, rulați „esxtop”. Apăsați „c” pentru vizualizarea CPU și ar trebui să vedeți o coloană „ % RDY ”Pentru CPU Ready. Puteți apăsa pe „ V ”Pentru vizualizarea VM Only.

Aici puteți vedea că% RDY este oarecum ridicat pentru un mediu destul de neutilizat. În acest caz, ESXi 5.5 rulează o VM de test pe VMware Fusion (hipervizor Mac), așa că este de așteptat să fie puțin la nivel înalt, deoarece rulăm o VM pe un hipervizor deasupra unui alt hipervizor.

În clientul vSphere, puteți trage în sus VM specifică și faceți clic pe fila Performanță. De acolo, faceți clic pe „Opțiuni grafic”

În Opțiuni grafic, selectați CPU, în timp real (dacă aveți vCenter, este posibil să aveți alte opțiuni de sincronizare decât cele în timp real). De acolo, în contoare, selectați „Gata”. Poate fi necesar să deselectați un contor diferit, deoarece vizualizarea permite doar două tipuri de date la un moment dat.

Veți observa că această valoare este o rezumare a gata față de un procent. Iată un link către un articol VMware KB despre cum să convertiți valorile sumare într-un procent. - https://kb.vmware.com/kb/2002181

Atunci când achiziționați hardware, mai multe nuclee contribuie la diminuarea impactului CPU Ready. Hyperthreading ajută, de asemenea. Deși Hyperthreading nu oferă un al doilea nucleu complet pentru fiecare nucleu primar, este de obicei suficient pentru a permite programarea vCPU în pCPU și pentru a ajuta la atenuarea problemei. Deși hipervizorii încep să se îndepărteze de la recomandarea raportului vCPU la pCPU, de obicei vă puteți descurca bine într-un mediu utilizat moderat cu un 4: 1 și puteți merge de acolo. Pe măsură ce începeți încărcarea mașinilor virtuale, priviți latența procesorului, pregătirea procesorului și senzația și performanța generală. Dacă aveți unele VM-uri puternice, vă recomandăm să le separați pe alte clustere și să utilizați un raport mai mic și să le mențineți ușoare. Pe de altă parte, pentru VM-urile în care performanța nu este esențială și este ok pentru ei să ruleze lent, vă puteți abona peste mult.

Dimensionarea corespunzătoare a VM-urilor este, de asemenea, un instrument imens pentru a combate CPU Ready. Mulți furnizori recomandă specificații cu privire la ceea ce ar putea avea nevoie VM. În mod tradițional, mai multe procesoare și mai multe nuclee = mai multă putere. Problema într-un mediu virtual este că hipervizorul trebuie să programeze toate vCPU-urile către pCPU-uri aproximativ în același timp și blocarea pCPU-urilor poate fi problematică. Dacă aveți o mașină virtuală 8 vCPU, trebuie să blocați 8 pCPU-uri pentru a le permite să programeze în același timp. Dacă vCPU VM utilizează doar 10% din totalul vCPU-urilor la un moment dat, este mai bine să aduceți numărul de vCPU în jos la 2 sau 4. Este mai bine să rulați o VM la 50-80% CPU cu mai puține vCPU-uri decât 10% la mai multe vCPU-uri. Această problemă este parțial deoarece programatorul CPU al sistemului de operare este conceput pentru a utiliza cât mai multe nuclee posibil, în timp ce, dacă ar fi instruit să maximizeze nucleele înainte de a utiliza mai multe, poate fi o problemă mai mică. O mașină virtuală supradimensionată poate funcționa bine, dar poate fi un „vecin zgomotos” pentru alte mașini virtuale, deci este de obicei un proces în care trebuie să parcurgeți toate mașinile virtuale din cluster la „dimensiunea corectă” pentru a vedea unele câștiguri de performanță.

De multe ori ați întâlnit CPU Ready și este dificil să începeți dimensionarea corectă a VM-urilor sau să faceți upgrade la procesoare cu mai multe nuclee. Dacă vă aflați în această situație, adăugarea mai multor gazde în clusterul dvs. vă poate ajuta să împărțiți sarcina pe mai multe gazde. Dacă aveți gazde cu mai multe nuclee / procesoare decât altele, legarea VM-urilor vCPU ridicate la aceste gazde de bază superioare vă poate ajuta, de asemenea. Doriți să vă asigurați gazda fizică care are cel puțin același număr de nuclee dacă nu mai mult decât VM, altfel va fi foarte lent / dificil să programați excesul de vCPU la pCPU, deoarece acestea trebuie blocate aproximativ în același timp .

În cele din urmă, hipervizorul dvs. poate accepta rezervări și limite pentru VM. Uneori, tezele se stabilesc accidental. Setările agresive pe acestea pot cauza pregătirea procesorului atunci când, de fapt, resursele subiacente sunt disponibile pentru acesta. De obicei, cel mai bine este să folosiți rezervările și limitele cu ușurință și numai atunci când este absolut necesar. În cea mai mare parte, un cluster de dimensiuni corespunzătoare va echilibra în mod adecvat resursele și acestea nu sunt de obicei necesare.

Pe scurt, cea mai bună apărare împotriva procesorului Ready este să știi că există și cum să îl verifici. Apoi puteți determina în mod sistematic cei mai buni pași de atenuare pentru mediul dvs., având în vedere cele de mai sus. În cea mai mare parte, informațiile din acest articol se aplică universal oricărui hipervizor, deși capturile de ecran și diagramele se aplică în mod specific VMware.