CPU Ready on midagi, mida te ei pruugi tunda. Esmamuljelt võib see kõlada heana, kuid kahjuks pole see nii. CPU Ready on virtuaalseid keskkondi vaevanud kauem, kui me teadsime, mis see on. VMware määratleb seda kui „protsentuaalsest ajast, mil virtuaalne masin oli valmis, kuid ei saanud ajastatud töötama füüsilisel protsessoril. Protsessori valmisoleku aeg sõltub hostis olevate virtuaalsete masinate arvust ja nende protsessori koormustest. ' Hyper-V hakkas alles hiljuti seda loendurit pakkuma (Hyper-V Hypervisori virtuaalne protsessor CPU ooteaeg lähetuse kohta) ja teised hüpervisorid ei pruugi seda mõõdikut endiselt pakkuda.
CPU-valmisoleku mõistmiseks peame mõistma, kuidas hüpervisorid ajastavad virtuaalsed protsessorid (vCPU) füüsilisteks protsessoriteks (pCPU). Kui VM-is on vaja vCPU aega, tuleb see vCPU (d) ajastada pCPU (de) ga, et käsud / protsessid / lõimed saaksid pCPU-ga töötada. Ideaalses maailmas pole ressursside konflikte ega kitsaskohti, kui see peaks juhtuma. Kui üks vCPU VM peab aja planeerima pCPU-ga, on pCPU tuum saadaval ja protsessori valmidus on selles ideaalses maailmas väga minimaalne. Oluline on märkida, et protsessori valmidus on alati olemas, kuid ideaalses maailmas on see väga minimaalne ja seda ei märgata.
Reaalses maailmas on virtualiseerimise üks eelis see, et võite kihla vedada, et paljud teie virtuaalsed masinad ei tõsta korraga kõiki oma vCPU-sid ja kui need on väga vähese kasutusega virtuaalseadmed, võite isegi arvata, kui palju saate laadige oma füüsiline host üles vastavalt protsessori ja RAM-i kasutamisele. Varem tehti soovitusi kasutada 4 vCPU kuni 1 pCPU või isegi 10: 1 suhet sõltuvalt töökoormusest. Näiteks võib teil olla üks neljatuumaline protsessor, kuid teil on 4 VM-i koos vCPU-dega, et anda teile 16 vCPU-d 4 pCPU-le või 4: 1. Insenerid hakkasid nägema siiski seda, et keskkonnad olid lihtsalt kohutavalt aeglased ja nad ei suutnud aru saada, miks. RAM-i kasutamine tundus hea, protsessori kasutamine füüsilistel hostidel võib isegi olla väga madal, alla 20%. Salvestamise latentsus oli äärmiselt madal, kuid VM-id olid siiski väga aeglased.
Selles stsenaariumis toimuv oli protsessori valmis. Ajastamiseks valmis vCPU oli järjekord, kuid pCPU-d ei olnud ajastamiseks võimalik. Hüpervisor seiskaks ajakava ja põhjustaks külaline VM-i latentsuse. See on vaikne tapja, mille avastamiseks polnud viimaste aastateni palju vahendeid. Windowsi VM-is kuluks alglaadimine igavesti ja siis, kui see lõpuks õnnestub, siis kui klõpsate menüül Start, võtab see ilmumise igavesti. Võite isegi klõpsata sellel uuesti, arvates, et see ei aktsepteerinud teie esimest klikki, ja kui see lõpuks järele jõuab, saate topeltklõpsu. Linuxis võib teie VM käivitada kirjutuskaitstud režiimi või vahetada failisüsteemid mingil hetkel hiljem ainult lugemisrežiimiks.
Niisiis, kuidas võidelda protsessori valmisoleku vastu? Aidata saab paaril viisil. Esiteks on protsessori valmisoleku mõõdikute jälgimine. VMware'is pole soovitatav minna üle 10%, kuid isikliku kogemuse põhjal hakkavad kasutajad märkama üle 5-7%, sõltuvalt VM-i tüübist ja sellest, mida see töötab.
Allpool kasutan CPU Ready kuvamiseks mõningaid näiteid VMware ESXi 5.5-st. Käivitage käsurea abil käsk “esxtop”. CPU vaate kuvamiseks vajutage klahvi 'c' ja peaksite nägema veergu ' % RDY ”Protsessori valmisoleku jaoks. Võite vajutada suurtähte “ V ”Ainult VM-i vaate jaoks.
Siit näete, et% RDY on üsna kasutamata keskkonna jaoks mõnevõrra kõrge. Sel juhul töötab minu ESXi 5.5 test VM-i VMware Fusioni (Mac hüpervisor) peal, nii et see peaks eeldatavasti olema natuke tipptasemel, kuna käitame VM-i hüpervisoril teise hüpervisori peal.
VSphere kliendis saate tõmmata konkreetse VM-i ja klõpsata vahekaardil Toimivus. Sealt kliki “Diagrammi valikud”
Valige diagrammivalikute alt protsessor, reaalajas (kui teil on vCenter, võib teil olla muid ajastamisvalikuid kui reaalajas). Sealt loendurites valige “Valmis”. Võimalik, et peate teise loenduri valiku tühistama, kuna vaade lubab igal ajahetkel ainult kahte andmetüüpi.
Pange tähele, et see väärtus on kokkuvõte valmis ja protsentides. Siin on link VMware KB artiklile selle kohta, kuidas kokkuvõtlikud mõõdikud protsentideks teisendada. - https://kb.vmware.com/kb/2002181
Riistvara ostmisel aitab rohkem südamikke vähendada protsessori valmisoleku mõju. Hüperniit aitab samuti. Ehkki Hyperthreading ei paku iga põhituuma jaoks täielikku teist tuuma, piisab tavaliselt sellest, et võimaldada vCPU ajastamine pCPU-ga ja aidata seda probleemi leevendada. Ehkki hüpervisorid hakkavad vCPU-st pCPU-suhte soovitusest eemalduma, saate tavaliselt mõõdukalt kasutatavas keskkonnas 4: 1-ga hästi hakkama ja sealt edasi minna. VM-i laadimise alustamisel vaadake protsessori latentsust, protsessori valmisolekut ning üldist enesetunnet ja jõudlust. Kui teil on mõni tugev lööv VM, võiksite need eraldada teistele klastritele ja kasutada väiksemat suhet ning hoida neid kergena. Teiselt poolt VM-ide puhul, kus jõudlus pole võtmetähtsusega ja on aeglane, kui nad aeglaselt töötavad, saate tellida palju kõrgemale.
VM-ide sobiv suuruse määramine on ka tohutu vahend protsessori valmisoleku vastu võitlemiseks. Paljud müüjad soovitavad spetsifikatsioone, mida VM võib tegelikult vajada. Traditsiooniliselt rohkem protsessoreid ja rohkem südamikke = rohkem energiat. Virtuaalse keskkonna probleem on see, et hüpervisor peab kõik vCPU-d ajastama pCPU-deks ligikaudu samal ajal ja pCPU-de lukustamine võib olla problemaatiline. Kui teil on 8 vCPU VM-i, peate lukustama 8 pCPU-d, et nad saaksid samal ajal ajastada. Kui teie vCPU VM kasutab igal ajahetkel ainult 10% kogu vCPU-st, on parem viia vCPU arv 2 või 4-ni. Parem on käivitada VM 50-80% protsessoriga vähem vCPU-dega kui 10% rohkem vCPU-sid. See probleem on osaliselt tingitud asjaolust, et operatsioonisüsteemi protsessori ajastaja on loodud kasutama võimalikult palju südamikke, samas kui see oleks koolitatud südamike maksimeerimiseks enne suurema hulga kasutamist, võib see olla vähem probleem. Suuremõõduline VM võib toimida hästi, kuid võib olla teiste VM-ide jaoks 'lärmakas naaber', nii et see on tavaliselt protsess, kus peate jõudluse kasvu nägemiseks läbima kõik klastri VM-id nende 'õiges suuruses'.
Mitu korda olete sattunud protsessori valmisolekusse ja on keeruline alustada VM-ide suuruse suuruse muutmist või täiendavate protsessoritega täiendamist. Kui olete sellises olukorras, aitab klastrisse lisada rohkem masinaid, et koormust jaotada rohkemate hostide vahel. Kui teil on hoste, millel on rohkem tuumasid / protsessoreid kui teistel, võib aidata ka kõrge vCPU virtuaalseadmete sidumine nende kõrgema tuumaga hostidega. Tahate tagada, et teie füüsilises hostis oleks vähemalt sama arv südamikke, kui mitte rohkem kui VM, vastasel juhul on väga aeglane / keeruline liigse vCPU ajastamine pCPU-sse, kuna need tuleb lukustada umbes samal ajal .
Lõpuks võib teie hüpervisor toetada VM-i reservatsioone ja piiranguid. Mõnikord seatakse teesid kogemata. Nende agressiivsed seaded võivad põhjustada protsessori valmisoleku, kui tegelikult on selle aluseks olevad ressursid olemas. Tavaliselt on kõige parem kasutada reservatsioone ja limiite säästlikult ja ainult siis, kui see on hädavajalik. Enamasti tasakaalustab korraliku suurusega klaster ressursse asjakohaselt ja neid pole tavaliselt vaja.
Kokkuvõtteks võib öelda, et parim kaitse CPU Ready vastu on teadmine, et see on olemas ja kuidas seda kontrollida. Seejärel saate ülaltoodust lähtudes süstemaatiliselt määrata oma keskkonnale parimad leevendusetapid. Enamasti kehtib selle artikli teave universaalselt kõigi hüpervisorite kohta, kuigi ekraanipildid ja diagrammid kehtivad spetsiaalselt VMware'i kohta.
5 minutit loetud
