CPU Ready er noe du kanskje ikke er kjent med. Ved førsteinntrykk kan det høres ut som en god ting, men dessverre er det ikke. CPU Ready har plaget virtuelle miljøer lenger enn vi visste hva det var. VMware definerer dette som 'Prosent av tid den virtuelle maskinen var klar, men ikke kunne planlegges å kjøre på den fysiske CPUen. CPU Ready-tid er avhengig av antall virtuelle maskiner på verten og deres CPU-belastning. ' Hyper-V begynte nylig å tilby denne telleren (Hyper-V Hypervisor Virtual prosessor CPU Ventetid per utsendelse), og andre hypervisorer kan fremdeles ikke gi denne beregningen.
For å forstå hva CPU Ready er, må vi forstå hvordan hypervisorer planlegger virtuelle CPUer (vCPU) til fysiske CPUer (pCPU). Når vCPU-tid er nødvendig i en virtuell maskin, må vCPU (er) planlegges mot pCPU (er) slik at kommandoene / prosessene / trådene kan kjøre mot pCPU. I en ideell verden er det ingen ressurskonflikter eller flaskehalser når dette må skje. Når en enkelt vCPU VM trenger å planlegge tid mot en pCPU, er en pCPU-kjerne tilgjengelig, og CPU Ready er veldig minimal i denne ideelle verden. Det er viktig å merke seg at CPU Ready alltid eksisterer, men i en ideell verden er den veldig minimal og ikke lagt merke til.
I den virkelige verden er en av fordelene med virtualisering at du kan satse på at mange av dine virtuelle maskiner ikke vil spike alle vCPU-ene sine samtidig, og hvis de er svært lite brukbare virtuelle maskiner, kan du til og med gjette på hvor mye du kan last opp din fysiske vert basert på CPU-bruk og RAM-bruk. Tidligere ble det gitt anbefalinger om å ha en 4 vCPU til 1 pCPU eller til og med 10: 1 avhengig av arbeidsmengden. For eksempel kan det hende du har en enkelt firekjerneprosessor, men har 4 virtuelle maskiner med vCPUer hver for å gi deg 16 vCPUer til 4 pCPUer eller 4: 1. Det ingeniørene begynte å se, er imidlertid at miljøene bare var veldig sakte, og de kunne ikke finne ut hvorfor. RAM-bruk virket bra, CPU-bruk på de fysiske vertene kan til og med være veldig lav, under 20%. Lagringsforsinkelsen var ekstremt lav, men VM-ene var ekstremt svake.
Det som skjedde i dette scenariet var CPU Ready. Det var en oppbygging av vCPU som var klar til å planlegges, men ingen pCPU tilgjengelig å planlegge mot. Hypervisoren stopper planleggingen og forårsaker ventetid for gjesten VM. Det er en stille morder som frem til de siste årene var det ikke mange verktøy å oppdage. I en Windows-VM vil det ta evig tid å starte, og når du endelig gjør det, når du klikker på startmenyen, vil det ta evig tid å dukke opp. Du kan til og med klikke på den igjen og tro at den ikke godtok ditt første klikk, og når det endelig innhenter, får du et dobbeltklikk. På Linux kan din VM starte opp i skrivebeskyttet modus eller til og med bytte filsystemene til skrivebeskyttet modus på et tidspunkt senere.
Så hvordan bekjemper vi CPU Ready? Det er noen måter som kan hjelpe. Først er å overvåke CPU-klare beregninger. I VMware anbefales det ikke å gå over 10%, men når det gjelder personlig erfaring, begynner brukerne å legge merke til over 5-7%, avhengig av typen VM og hva den kjører.
Nedenfor vil jeg bruke noen eksempler fra VMware ESXi 5.5 for å vise CPU Ready. Kjør “esxtop” ved hjelp av kommandolinjen. Trykk “c” for CPU-visning, og du bør se en kolonne “ % RDY ”For CPU Ready. Du kan trykke på ' V ”For VM Only-visning.
Her kan du se at% RDY er noe høyt for et ganske ubrukt miljø. I dette tilfellet kjører min ESXi 5.5 en test-VM på toppen av VMware Fusion (Mac hypervisor), så det forventes å være litt i høysiden, siden vi kjører en VM på en hypervisor på toppen av en annen hypervisor.
I vSphere-klienten kan du trekke opp den spesifikke virtuelle maskinen og klikke på kategorien Ytelse. Derfra klikker du på 'Kartalternativer'
Velg CPU, sanntid i kartalternativer (hvis du har vCenter, kan du ha andre tidsalternativer enn sanntid). Derfra i Counters, velg “Ready”. Det kan hende du må oppheve valget av en annen teller da visningen bare tillater to datatyper til enhver tid.
Du vil merke at denne verdien er en oppsummering av klar versus prosent. Her er en lenke til en VMware KB-artikkel om hvordan du konverterer de oppsummerte beregningene til en prosentandel. - https://kb.vmware.com/kb/2002181
Når du kjøper maskinvare, hjelper flere kjerner med å redusere effekten av CPU Ready. Hyperthreading hjelper også. Selv om Hyperthreading ikke gir en fullstendig andre kjerne for hver primære kjerne, er det vanligvis nok å tillate planlegging av vCPU til pCPU og bidra til å redusere problemet. Selv om hypervisorer begynner å bevege seg bort fra anbefaling av vCPU til pCPU-forhold, kan du vanligvis gjøre det bra i et moderat brukt miljø med en 4: 1 og gå derfra. Når du begynner å laste inn virtuelle maskiner, se på CPU-ventetid, CPU-klar og generell følelse og ytelse. Hvis du har noen hardt rammende virtuelle maskiner, kan det være lurt å adskille dem på andre klynger og bruke et lavere forhold og holde dem lette. På den annen side for virtuelle maskiner der ytelse ikke er nøkkelen og det er ok for dem å kjøre svak, kan du abonnere mye høyere.
Å dimensjonere VM-er riktig er også et stort verktøy for å bekjempe CPU Ready. Mange leverandører anbefaler spesifikasjoner godt over hva VM faktisk kan trenge. Tradisjonelt flere CPUer og flere kjerner = mer kraft. Problemet i et virtuelt miljø er at hypervisoren må planlegge alle vCPUene til pCPUene omtrent samtidig, og det kan være problematisk å låse pCPUene. Hvis du har en 8 vCPU VM, må du låse 8 pCPUer for å la dem planlegge samtidig. Hvis din vCPU VM bare bruker 10% av total vCPU til enhver tid, er det bedre å bringe vCPU-tellingen ned til 2 eller 4. Det er bedre å kjøre en VM på 50-80% CPU med mindre vCPU enn 10% ved flere vCPUer. Dette problemet skyldes delvis at operativsystemets CPU-planlegger er designet for å bruke så mange kjerner som mulig, mens hvis det ble opplært til å maksimere kjerner før du bruker mer, kan det være mindre av et problem. En stor VM kan fungere bra, men kan være en 'støyende nabo' for andre virtuelle maskiner, så det er vanligvis en prosess der du må gå gjennom alle virtuelle maskiner i klyngen for å 'riktig størrelse' dem for å se noen ytelsesgevinster.
Mange ganger har du fått CPU-klar, og det er vanskelig å starte riktig størrelse på virtuelle maskiner eller oppgradere til prosessorer med flere kjerner. Hvis du er i denne situasjonen, kan du legge til flere verter i klyngen din for å spre belastningen over flere verter. Hvis du har verter med flere kjerner / prosessorer enn andre, kan det også hjelpe å knytte høye vCPU-virtuelle maskiner til disse høyere kjernevertene. Du vil sikre at din fysiske vert har minst samme antall kjerner hvis ikke mer enn VM, ellers vil det være veldig sakte / vanskelig å planlegge overskuddet av vCPU til pCPU, siden de må låses omtrent samtidig .
Til slutt kan hypervisoren din støtte reservasjoner og begrensninger på VM. Noen ganger blir avhandlingene satt ved et uhell. Aggressive innstillinger på disse kan føre til at CPU er klar når de underliggende ressursene faktisk er tilgjengelige for det. Det er vanligvis best å bruke reservasjoner og grenser sparsomt og bare når det er absolutt nødvendig. For det meste vil en klynge med riktig størrelse balansere ressurser på riktig måte, og disse er vanligvis ikke nødvendig.
Oppsummert er det beste forsvaret mot CPU Ready å vite at den eksisterer og hvordan du ser etter den. Du kan deretter systematisk bestemme de beste avbøtingstrinnene for miljøet ditt gitt ovennevnte. For det meste gjelder informasjonen i denne artikkelen universelt for enhver hypervisor, selv om skjermbilder og diagrammer gjelder spesielt for VMware.
5 minutter lest
