Pripravljen na CPU: Tihi hipervizorni morilec

CPU Ready je nekaj, česar morda niste seznanjeni. Na prvi vtis se morda sliši dobro, a na žalost ni. CPU Ready že dolgo muči navidezna okolja, kot smo vedeli, za kaj gre. VMware to opredeli kot „Odstotek časa, ko je bil navidezni stroj pripravljen, vendar ni mogel načrtovati zagon na fizičnem CPU. Čas pripravljenosti za CPU je odvisen od števila navideznih strojev na gostitelju in njihovih obremenitev procesorja. ' Hyper-V je šele pred kratkim začel zagotavljati ta števec (navidezni procesor Hyper-V Hypervisor CPU Čakalni čas na odpremo) in drugi hipervizorji te meritve morda še vedno ne zagotavljajo.

Da bi razumeli, kaj je CPU Ready, bomo morali razumeti, kako hipervizorji razporejajo virtualne CPU (vCPU) na fizične CPU (pCPU). Če je v VM potreben čas vCPU, je treba vCPU (-e) razporediti proti pCPU-jem, da se lahko ukazi / procesi / niti izvajajo proti pCPU-ju. V idealnem svetu ni konfliktov z viri ali ozkih grl, ko se to mora zgoditi. Ko mora en sam vCPU VM določiti čas glede na pCPU, je na voljo jedro pCPU in CPU Ready je v tem idealnem svetu zelo minimalen. Pomembno je omeniti, da CPU Ready vedno obstaja, vendar je v idealnem svetu zelo minimalen in ni opazen.

V resničnem svetu je ena od prednosti virtualizacije ta, da lahko stavite, da številni vaši VM-ji ne bodo istočasno dodali vseh svojih vCPU-jev, in če so ti VM-ji zelo majhni, lahko celo ugibate, koliko lahko naložite fizični gostitelj glede na porabo procesorja in RAM. V preteklosti so bila podana priporočila za uporabo 4 vCPU na 1 pCPU ali celo razmerje 10: 1, odvisno od delovne obremenitve. Na primer, morda imate en štirijedrni procesor, vendar imate 4 VM-je z vCPU-ji, da boste dobili 16 vCPU-jev na 4 pCPU-je ali 4: 1. Inženirji pa so začeli ugotavljati, da so bila okolja strašno počasna in niso mogli ugotoviti, zakaj. Poraba RAM-a se je zdela v redu, poraba procesorja na fizičnih gostiteljih je lahko celo zelo majhna, pod 20%. Latencija shranjevanja je bila izredno majhna, kljub temu pa so bili VM-ji zelo počasni.

V tem scenariju se je dogajalo CPU Ready. VCPU je bil v čakalni vrsti, pripravljen za razpored, vendar ni na voljo pCPU za razporejanje. Hipervizor bi zaustavil razporejanje in povzročil zakasnitev gostujočega VM. Tihi morilec je, da do zadnjih let ni bilo veliko orodij za odkrivanje. V Windows VM bi zagon trajal večno, nato pa, ko končno, ko kliknete meni Start, traja večno, da se prikaže. Lahko ga celo znova kliknete, če mislite, da ni sprejel vašega prvega klika, in ko bo končno dohitel, boste dobili dvojni klik. V Linuxu se lahko vaš VM kasneje zažene v način samo za branje ali celo preklopi datotečni sistem v način samo za branje.

Torej, kako se boriti proti CPU Ready? Obstaja nekaj načinov, ki vam lahko pomagajo. Prvi je spremljanje meritev CPU Ready. V VMware ni priporočljivo, da presežete 10%, vendar v osebnih izkušnjah uporabniki začnejo opazovati nad 5-7%, odvisno od vrste VM in tega, kaj se izvaja.

Spodaj bom uporabil nekaj primerov iz VMware ESXi 5.5 za prikaz CPU Ready. V ukazni vrstici zaženite »esxtop«. Pritisnite 'c' za pogled CPU in prikazal bi se stolpec ' % RDY ”Za CPU pripravljen. Lahko pritisnete kapital “ V ”Za ogled samo VM.

Tu lahko vidite, da je% RDY nekoliko visok za dokaj neuporabljeno okolje. V tem primeru moj ESXi 5.5 izvaja preizkusni VM na vrhu VMware Fusion (Mac hypervisor), zato naj bi bil nekoliko na višjem nivoju, saj izvajamo VM na hipervizorju na vrhu drugega hipervizorja.

V odjemalcu vSphere lahko povlečete določen VM in kliknete zavihek Performance. Od tam kliknite na 'Možnosti grafikona'

V meniju Chart Options izberite CPU, Real-time (če imate vCenter, imate morda tudi druge časovne možnosti kot v realnem času). Od tam v števcih izberite »Pripravljeno«. Morda boste morali odstraniti izbiro drugega števca, saj pogled v določenem trenutku dovoljuje samo dve podatkovni vrsti.

Opazili boste, da je ta vrednost povzetek pripravljenosti v primerjavi z odstotki. Tu je povezava do članka VMware KB o pretvorbi povzetih meritev v odstotek. - https://kb.vmware.com/kb/2002181

Pri nakupu strojne opreme več jeder pomaga zmanjšati vpliv CPU Ready. Pomaga tudi hipernitanje. Medtem ko Hyperthreading ne zagotavlja celotnega drugega jedra za vsako primarno jedro, je običajno dovolj, da omogočite razporejanje vCPU na pCPU in pomagate ublažiti težavo. Čeprav se hipervizorji začenjajo odmikati od priporočila za razmerje vCPU in pCPU, lahko v srednje uporabljenem okolju s 4: 1 običajno dobro delate in od tam nadaljujete. Ko začnete nalagati VM, si oglejte zakasnitev CPU, pripravljenost za CPU ter splošen občutek in zmogljivost. Če imate nekaj težkih VM-jev, jih boste morda želeli ločiti v druge gruče in uporabiti nižje razmerje ter jih ohraniti lahke. Po drugi strani pa za VM-je, kjer zmogljivost ni ključna in je v redu, če delujejo počasi, se lahko naročite veliko višje.

Primerna velikost VM je tudi izjemno orodje za boj proti CPU Ready. Številni prodajalci priporočajo specifikacije v bistvu glede tega, kaj VM morda dejansko potrebuje. Tradicionalno več procesorjev in več jeder = več energije. Težava v navideznem okolju je, da mora hipervizor približno istočasno razporediti vse vCPU-je na pCPU-je in zaklepanje pCPU-jev je lahko problematično. Če imate 8 vCPU VM, morate zakleniti 8 pCPU, da jim omogočite načrtovanje hkrati. Če vaša vCPU VM v določenem trenutku porabi le 10% celotnih vCPU-jev, vam je bolje, če odštejete vCPU na 2 ali 4. Bolje je, da zaženete VM s 50-80% CPU z manj vCPU kot 10% na več vCPU-jev. Ta težava je deloma posledica tega, ker je načrtovalnik CPU operacijskega sistema zasnovan tako, da uporablja čim več jeder, če pa je bil usposobljen za maksimiranje jeder, preden je uporabil več, je morda manjši problem. Prevelik VM se lahko dobro obnese, vendar je lahko za druge VM 'hrupni sosed', zato je to običajno postopek, pri katerem morate skozi 'VM' v gruči 'določiti pravo velikost', da si ogledate nekaj povečanja učinkovitosti.

Velikokrat ste že naleteli na CPU Ready in je težko začeti pravilno spreminjati velikost VM-jev ali nadgraditi na procesorje z več jedri. Če ste v tej situaciji, lahko dodajanje več gostiteljev v vašo gručo pomaga pri širjenju obremenitve na več gostiteljev. Če imate gostitelje z več jedri / procesorji kot drugi, vam lahko pomaga tudi vezanje visokih vCPU VM na te višje jedrne gostitelje. Želite zagotoviti, da ima vaš fizični gostitelj vsaj enako število jeder, če ne več kot VM, sicer bo zelo počasi / težko načrtovati presežek vCPU na pCPU, ker jih je treba zakleniti približno istočasno .

Končno lahko vaš hipervizor podpira rezervacije in omejitve VM. Včasih se teze postavijo po naključju. Agresivne nastavitve na njih lahko povzročijo, da je CPU pripravljen, če so mu dejansko na voljo osnovni viri. Običajno je najbolje, da pridržke in omejitve uporabljate zmerno in le, kadar je to nujno potrebno. Večinoma bo grozd primerne velikosti ustrezno uravnotežil vire, ki običajno niso potrebni.

Če povzamemo, najboljša obramba pred CPU Ready je vedeti, da obstaja in kako jo preveriti. Nato lahko sistematično določite najboljše korake za ublažitev vašega okolja glede na zgoraj. Informacije v tem članku se večinoma nanašajo na kateri koli hipervizor, čeprav se posnetki zaslona in grafikoni nanašajo posebej na VMware.