CPU Ready er noget, som du måske ikke kender. Ved første indtryk kan det lyde som en god ting, men desværre er det ikke. CPU Ready har plaget virtuelle miljøer i længere tid, end vi vidste hvad det var. VMware definerer dette som 'Procentdel af tid, at den virtuelle maskine var klar, men ikke kunne blive planlagt til at køre på den fysiske CPU. CPU Ready-tid afhænger af antallet af virtuelle maskiner på værten og deres CPU-belastninger. ” Hyper-V startede først for nylig med at levere denne tæller (Hyper-V Hypervisor Virtual processor CPU Ventetid pr. Forsendelse), og andre hypervisorer giver muligvis stadig ikke denne metric.
For at forstå hvad CPU Ready er, bliver vi nødt til at forstå, hvordan hypervisorer planlægger virtuelle CPU'er (vCPU) til fysiske CPU'er (pCPU). Når der er behov for vCPU-tid i en VM, skal vCPU (er) planlægges mod pCPU (r), så kommandoerne / processerne / tråde kan køre mod pCPU'en. I en ideel verden er der ingen ressourcekonflikter eller flaskehalse, når dette skal ske. Når en enkelt vCPU VM skal planlægge tid mod en pCPU, er en pCPU-kerne tilgængelig, og CPU Ready er meget minimal i denne ideelle verden. Det er vigtigt at bemærke, at CPU Ready altid eksisterer, men i en ideel verden er den meget minimal og ikke bemærket.
I den virkelige verden er en af fordelene ved virtualisering, at du kan satse på, at mange af dine virtuelle computere ikke vil spike alle deres vCPU'er på samme tid, og hvis de er meget brugbare VM'er, kan du endda gætte på, hvor meget du kan indlæse din fysiske vært baseret på CPU-brug og RAM-brug. Tidligere blev der fremsat henstillinger om at have et 4 vCPU til 1 pCPU eller endda 10: 1-forhold afhængigt af arbejdsbyrden. For eksempel kan du have en enkelt quad-core processor, men har en 4 VM'er med vCPU'er hver for at give dig 16 vCPU'er til 4 pCPU'er eller 4: 1. Hvad ingeniører begyndte at se, er imidlertid, at omgivelserne bare var forfærdelige langsomme, og de kunne ikke finde ud af hvorfor. RAM-brug syntes fint, CPU-brug på de fysiske værter kan endda være meget lav, under 20%. Lagringsforsinkelse var ekstremt lav, men VM'erne var ekstremt træg.
Hvad der skete i dette scenarie var CPU Ready. Der var en køopbygning af vCPU klar til at blive planlagt, men ingen pCPU tilgængelig til planlægning mod. Hypervisoren stopper planlægningen og forårsager latenstid for gæstens VM. Det er en tavs morder, at der indtil de seneste år ikke var mange værktøjer til at opdage. I en Windows VM tager det evigt at starte, og når det endelig gør det, når du klikker på startmenuen, vil det tage evigt at dukke op. Du kan endda klikke på det igen og tro, at det ikke accepterede dit første klik, og når det endelig indhenter, får du et dobbeltklik. På linux kan din VM muligvis starte op i skrivebeskyttet tilstand eller endda skifte filsystemerne til skrivebeskyttet tilstand på et eller andet tidspunkt senere.
Så hvordan bekæmper vi CPU Ready? Der er et par måder, der kan hjælpe. Først overvåges CPU-klare metrics. I VMware anbefales det ikke at gå over 10%, men i personlig erfaring begynder brugerne at bemærke over 5-7% afhængigt af typen af VM og hvad den kører.
Nedenfor vil jeg bruge nogle eksempler fra VMware ESXi 5.5 til at vise CPU Ready. Brug kommandolinjen til at køre “esxtop”. Tryk på 'c' for CPU-visning, og du skal se en kolonne ' % RDY ”Til CPU-klar. Du kan trykke på ' V ”Til Vis kun VM.
Her kan du se, at% RDY er noget højt for et ret ubrugt miljø. I dette tilfælde kører min ESXi 5.5 en test-VM oven på VMware Fusion (Mac hypervisor), så det forventes at være lidt i den høje ende, da vi kører en VM på en hypervisor oven på en anden hypervisor.
I vSphere-klienten kan du trække den specifikke VM op og klikke på fanen Performance. Derfra skal du klikke på 'Chart Options'
Inden for diagramindstillinger skal du vælge CPU, Realtid (hvis du har vCenter, har du muligvis andre timingindstillinger end realtid). Derfra i tællerne skal du vælge “Klar”. Du skal muligvis fravælge en anden tæller, da visningen kun tillader to datatyper på et givet tidspunkt.
Du vil bemærke, at denne værdi er en sammenfatning af klar versus en procentdel. Her er et link til en VMware KB-artikel om, hvordan man konverterer de opsummerede metrics til en procentdel. - https://kb.vmware.com/kb/2002181
Når du køber hardware, hjælper flere kerner med at mindske virkningen af CPU Ready. Hyperthreading hjælper også. Mens hyperthreading ikke giver en fuld anden kerne til hver primære kerne, er det normalt nok til at tillade planlægning af vCPU til pCPU og hjælpe med at afbøde problemet. Selv om hypervisorer begynder at bevæge sig væk fra vCPU til pCPU-forholdsanbefaling, kan du normalt klare dig godt i et moderat anvendt miljø med en 4: 1 og gå derfra. Når du begynder at indlæse virtuelle computere, skal du se på CPU-latenstid, CPU-klar og generel følelse og ydeevne. Hvis du har nogle hårdt ramte virtuelle computere, vil du måske adskille dem på andre klynger og bruge et lavere forhold og holde dem lette. På den anden side for virtuelle computere, hvor ydeevne ikke er nøglen, og det er ok for dem at køre træg, kan du abonnere meget højere.
At dimensionere VM'erne korrekt er også et stort værktøj til at bekæmpe CPU Ready. Mange leverandører anbefaler specifikationer langt over, hvad VM faktisk kan have brug for. Traditionelt flere CPU'er og flere kerner = mere strøm. Problemet i et virtuelt miljø er, at hypervisoren skal planlægge alle vCPU'erne til pCPU'erne på omtrent samme tid, og det kan være problematisk at låse pCPU'erne. Hvis du har en 8 vCPU VM, skal du låse 8 pCPU'er, så de kan planlægge på samme tid. Hvis din vCPU VM kun bruger 10% af de samlede vCPU'er til enhver tid, er det bedre at bringe vCPU-antallet ned til 2 eller 4. Det er bedre at køre en VM på 50-80% CPU med mindre vCPU'er end 10% ved flere vCPU'er. Dette problem skyldes dels, at operativsystemets CPU-planlægger er designet til at bruge så mange kerner som muligt, mens det, hvis det blev uddannet til at maksimere kerner, inden du bruger mere, kan være mindre problem. En overdimensioneret VM fungerer muligvis godt, men kan være en 'støjende nabo' for andre virtuelle computere, så det er normalt en proces, hvor du skal gennem alle VM'er i klyngen for at 'rette størrelse' for at se nogle præstationsgevinster.
Mange gange har du kørt ind i CPU Ready, og det er svært at starte højre størrelse på VM'er eller opgradere til processorer med flere kerner. Hvis du er i denne situation, kan tilføjelse af flere værter i din klynge hjælpe med dette for at sprede belastningen på flere værter. Hvis du har værter med flere kerner / processorer end andre, kan tilknytning af høje vCPU-VM'er til disse højere kerneværter også hjælpe. Du vil sikre, at din fysiske vært har mindst det samme antal kerner, hvis ikke mere end VM, ellers vil det være meget langsomt / vanskeligt at planlægge overskuddet af vCPU til pCPU, da de skal låses omtrent på samme tid .
Endelig kan din hypervisor muligvis understøtte forbehold og begrænsninger på VM. Nogle gange bliver afhandlinger ved et uheld sat. Aggressive indstillinger på disse kan medføre, at CPU er klar, når de underliggende ressourcer faktisk er tilgængelige for den. Det er normalt bedst at bruge reservationer og grænser sparsomt og kun når det er absolut nødvendigt. For det meste vil en klynge med en korrekt størrelse afbalancere ressourcer korrekt, og disse er typisk ikke nødvendige.
Sammenfattende er det bedste forsvar mod CPU Ready at vide, at det findes, og hvordan man kontrollerer det. Du kan derefter systematisk bestemme de bedste afbødningstrin for dit miljø i betragtning af ovenstående. For det meste gælder oplysningerne i denne artikel universelt for enhver hypervisor, selvom skærmbilleder og diagrammer gælder specifikt for VMware.
5 minutter læst
