CPU Klar: Den Silent Hypervisor Killer

CPU Ready er noe du kanskje ikke er kjent med. Ved et første inntrykk 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 prosenten av tid som den virtuelle maskinen var klar, men kunne ikke bli planlagt til å kjøre på den fysiske CPU. CPU Klar tid er avhengig av antall virtuelle maskiner på verten og deres CPU-belastninger. Hyper-V bare nylig startet å levere denne telleren (Hyper-V Hypervisor Virtual prosessor \ CPU Ventetid per forsendelse) og andre hypervisorer kan fortsatt ikke gi denne metriske.

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 VM, må vCPU (e) planlegges mot pCPU (e) slik at kommandoer / prosesser / tråder kan løpe 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 det svært 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 VM ikke vil spike alle sine vCPUer samtidig, og hvis de er svært lave bruks VM, kan du til og med gjøre gjetninger om hvor mye du kan Last opp din fysiske vert basert på CPU bruk og RAM bruk. Tidligere ble det gjort anbefalinger om å ha en 4 vCPU til 1 pCPU eller til og med 10: 1-forholdet avhengig av arbeidsbelastning. For eksempel kan du ha en enkelt quad core prosessor, men har en 4 VM med vCPUer hver for å gi deg 16 vCPUer til 4 pCPUer eller 4: 1. Hvilke ingeniører begynte å se skjønt er at miljøene var bare veldig treg og de kunne ikke finne ut hvorfor. RAM-bruken virket fint, CPU-bruken på de fysiske vertene kan til og med være svært lav, under 20%. Lagringstid var ekstremt lav, men VMene var ekstremt treg.

Det som skjedde i dette scenariet var CPU Ready. Det var en kø oppbygging av vCPU klar til å bli planlagt, men ingen pCPU tilgjengelig for planlegging mot. Hypervisoren ville stoppe planleggingen og forårsake latens for gjesten VM. Det er en stille morder som frem til de siste årene, var det ikke mange verktøy for å oppdage. I en Windows VM vil det ta for alltid å starte opp, og når det endelig gjøres, vil det ta for alltid å komme opp når du klikker på startmenyen. Du kan til og med klikke på den igjen og tenke at den ikke aksepterte ditt første klikk og når det endelig kommer opp, får du et dobbeltklikk. På Linux kan din VM starte opp i skrivebeskyttet modus eller til og med bytte filsystemene til skrivebeskyttet modus noen gang senere.

Så hvordan bekjemper vi CPU Ready? Det er noen måter som kan hjelpe. Først overvåker CPU Ready beregninger. I VMware anbefales det ikke å gå over 10%, men i personlig erfaring begynner brukerne å merke 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. Bruk kommandolinjen, kjør esxtop. Trykk c for CPU-visning, og du bør se en kolonne % RDY for CPU Ready. Du kan trykke på kapital 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øyden, siden vi kjører en VM på hypervisor på toppen av en annen hypervisor.

I vSphere-klienten kan du trekke opp den spesifikke VM og klikke på Ytelse-fanen. Derfra klikker du på Chart Options

I diagramalternativer velger du CPU, sanntid (hvis du har vCenter, kan du ha andre tidsalternativer enn sanntid). Derfra i tellerne, velg Klar. Det kan hende du må velge bort en annen teller fordi visningen bare tillater to datatyper til enhver tid.

Du vil merke at denne verdien er en oppsummering av klar mot en prosentandel. 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

Ved kjøp av maskinvare bidrar flere kjerner til å redusere effekten av CPU Ready. Hyperthreading hjelper også. Selv om Hyperthreading ikke gir en full sekundær kjerne for hver primærkjerne, er det vanligvis nok å tillate å planlegge vCPU til pCPU og bidra til å redusere problemet. Selv om hypervisorer begynner å bevege seg fra vCPU til pCPU-forholds anbefaling, kan du vanligvis gjøre det bra i et moderat brukt miljø med en 4: 1 og gå derfra. Når du begynner å laste VM, ser du på CPU-latens, CPU-klar og generell følelse og ytelse. Hvis du har noen kraftige slående VM, kan det være lurt å segregere dem på andre klynger og bruke et lavere forhold og holde dem lyse. På den annen side for VMer hvor ytelsen ikke er nøkkelen, og det er greit for dem å kjøre treg, kan du over abonnere mye høyere.

Å målrette VM'ene riktig er også et stort verktøy for å bekjempe CPU Ready. Mange leverandører anbefaler spesifikasjoner godt over hva VM kanskje trenger. Tradisjonelt flere CPUer og flere kjerner = mer kraft. Problemet i et virtuelt miljø er at hypervisoren må planlegge alle vCPUene til pCPUs på omtrent samme tid, og låsing av pCPUene kan være problematisk. Hvis du har en 8 vCPU VM, må du låse 8 pCPUer slik at de kan planlegge på samme tid. Hvis din vCPU VM bare bruker 10% av de totale vCPUene til enhver tid, er det bedre å bringe vCPU-telling ned til 2 eller 4. Det er bedre å kjøre en VM ved 50-80% CPU med mindre vCPU enn 10% ved flere vCPUer. Dette problemet er delvis fordi operativsystemet CPU scheduler er designet for å bruke så mange kjerner som mulig, men hvis det ble trent til å maksimere kjerner før du bruker mer, kan det være mindre av et problem. En overdimensjonert VM kan fungere bra, men det kan være en støyende nabo for andre VM, så det er vanligvis en prosess hvor du må gå gjennom alle VMs i klyngen til riktig størrelse for å se noen prestasjonsgevinster.

Mange ganger har du kjørt inn i CPU Ready, og det er vanskelig å starte riktig størrelsen på VM eller oppgradering 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 hende at det henger sammen med høye vCPU VMs til disse høyere kjerneherdene. Du vil sikre din fysiske vert som har minst samme antall kjerner hvis ikke mer enn VM, ellers vil det være veldig sakte / vanskelig å planlegge overskytdet av vCPU til pCPU siden de må låses på omtrent samme tid .

Endelig kan hypervisoren din støtte forbehold og begrensninger på VM. Noen ganger blir disse satt ved et uhell. Aggressive innstillinger på disse kan føre til at CPU er klar når faktisk de underliggende ressursene er tilgjengelige for det. Det er vanligvis best å bruke reservasjoner og begrenser sparsomt og bare når det er absolutt nødvendig. For det meste vil en riktig størrelse klynge på passende måte balansere ressurser, og disse er vanligvis ikke nødvendig.

I sammendraget er det beste forsvaret mot CPU Ready å vite at det eksisterer og hvordan man skal sjekke det. Du kan deretter systematisk avgjøre de beste begrensningstrinnene for ditt miljø gitt ovenstående. For det meste gjelder informasjonen i denne artikkelen universelt for noen hypervisor, selv om skjermbilder og diagrammer gjelder spesielt for VMware.

PRO TIPS: Hvis problemet er med datamaskinen eller en bærbar PC / notatbok, bør du prøve å bruke Reimage Plus-programvaren som kan skanne arkiver og erstatte skadede og manglende filer. Dette fungerer i de fleste tilfeller der problemet er oppstått på grunn av systemkorrupsjon. Du kan laste ned Reimage Plus ved å klikke her