CPU Klar: Den Silent Hypervisor Killer

CPU Ready er noget, som du måske ikke er bekendt med. Ved et første indtryk kan det lyde som en god ting, men det er desværre ikke det. CPU Ready har plaget virtuelle miljøer i længere tid end vi vidste hvad det var. VMware definerer dette som den procentdel af tid, som den virtuelle maskine var klar til, men kunne ikke blive planlagt til at køre på den fysiske CPU. CPU Ready tid er afhængig af antallet af virtuelle maskiner på værten og deres CPU belastninger. Hyper-V blev først for nylig begyndt at levere denne tæller (Hyper-V Hypervisor Virtual Processor \ CPU Ventetid pr. Afsendelse) og andre hypervisorer kan stadig ikke levere denne metriske.

For at forstå, hvad CPU Ready er, skal vi forstå, hvordan hypervisorer planlægger virtuelle CPU'er (vCPU) til fysiske CPU'er (pCPU). Når vCPU-tid er nødvendig i en VM, skal vCPU (e) planlægges mod pCPU (er), så kommandoer / processer / tråde kan køre mod pCPU. I en ideel verden er der ingen ressourcekonflikter eller flaskehalse, når dette skal ske. Når en enkelt vCPU VM skal planlægge tiden 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 det 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 VM'er ikke vil spike alle deres vCPU'er samtidig, og hvis de er meget lavt anvendte VM'er, kan du endda lave gæt på, hvor meget du kan Upload din fysiske vært baseret på CPU-brug og RAM-brug. Tidligere blev der lavet anbefalinger til at have et 4 vCPU til 1 pCPU eller endda 10: 1-forholdet afhængigt af arbejdsbyrden. For eksempel kan du have en enkelt quad core-processor, men har 4 VM'er med vCPU'er hver for at give dig 16 vCPU'er til 4 pCPU'er eller 4: 1. Hvilke ingeniører begyndte at se er imidlertid, at miljøerne var bare forfærdeligt langsomt, og de kunne ikke finde ud af hvorfor. RAM brug syntes fint, CPU forbrug på de fysiske værter kan endda være meget lav, under 20%. Lager latens var ekstremt lav, men VM'erne var ekstremt træg.

Hvad der skete i dette scenario var CPU Ready. Der var en kø opbygning af vCPU klar til at blive planlagt, men ingen pCPU tilgængelig til at planlægge imod. Hypervisoren ville stoppe planlægningen og forårsage latens for gæsten VM. Det er en stille morder, der indtil de seneste år var der ikke mange værktøjer til at opdage. I en Windows VM, ville det tage for evigt at starte, og så når det endelig gør, når du klikker på startmenuen, ville det tage for 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 kommer op, får du et dobbelt klik. På linux kan din VM starte op i read-only tilstand eller endda skifte filsystemer til læsningstilstand et tidspunkt senere.

Så hvordan bekæmper vi CPU Ready? Der er et par måder der kan hjælpe. For det første overvåger CPU Ready-metrics. I VMware anbefales det ikke at gå over 10%, men i personlig oplevelse begynder brugerne at opleve over 5-7% afhængigt af typen 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 løbe esxtop. Tryk c for CPU visning, og du skal se en kolonne % RDY for CPU Ready. Du kan trykke på kapital V for VM Only visning.

Her kan du se, at% RDY er noget højt for et forholdsvis 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 op på den specifikke VM og klikke på fanen Performance. Derfra klikker du på Chart Options

PRO TIP: Hvis problemet er med din computer eller en bærbar computer / notesbog, skal du prøve at bruge Reimage Plus-softwaren, som kan scanne lagrene og udskifte korrupte og manglende filer. Dette virker i de fleste tilfælde, hvor problemet er opstået på grund af systemkorruption. Du kan downloade Reimage Plus ved at klikke her

Inden for Chart Options, vælg CPU, Real-time (hvis du har vCenter, kan du have andre timing muligheder end i realtid). Derefter i tællerne, vælg Klar. Det kan være nødvendigt at afmarkere en anden tæller, da visningen kun tillader to datatyper til enhver tid.

Du vil bemærke, at denne værdi er en opsummering af klar i forhold til en procentdel. Her er et link til en VMware KB-artikel om, hvordan du konverterer de opsummerede metricer til en procentdel. - https://kb.vmware.com/kb/2002181

Ved køb af hardware hjælper flere kerner med at mindske virkningen af CPU Ready. Hyperthreading hjælper også. Mens Hyperthreading ikke giver en fuld sekundær kerne for hver primære kerne, er det normalt nok at tillade planlægning af vCPU'en til pCPU og hjælpe med at mildne problemet. Selv om hypervisorer begynder at bevæge sig væk fra vCPU til pCPU ratio anbefaling, kan du normalt gøre det godt i et moderat anvendt miljø med en 4: 1 og gå derfra. Når du begynder at læse VM'er, ser du på CPU-latency, CPU-klar og samlet følelse og ydeevne. Hvis du har nogle stærke rammende VM'er, vil du måske adskille dem på andre klynger og bruge et lavere forhold og holde dem lyse. På den anden side for VM'er, hvor ydeevnen ikke er nøglen, og det er ok for dem at køre træg, kan du over til at abonnere meget højere.

Tilpasning af VM'erne korrekt er også et stort værktøj til at bekæmpe CPU Ready. Mange leverandører anbefaler specifikationer godt over, hvad VM måske rent faktisk har 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'er på omtrent samme tid, og låsning af pCPU'erne kan være problematisk. 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 på et givet tidspunkt, er du bedre til at bringe vCPU-tællingen ned til 2 eller 4. Det er bedre at køre en VM ved 50-80% CPU med mindre vCPU'er end 10% ved flere vCPU'er. Dette problem skyldes dels, at operativsystemet CPU scheduler er designet til at bruge så mange kerner som muligt, men hvis det blev trænet til max ud kerner, før du bruger mere, kan det være mindre af et problem. En overdimensioneret VM kan klare sig godt, men det kan være en støjende nabo til andre VM'er, så det er normalt en proces, hvor du skal gennemgå alle VM'er i klyngen for at få dem til at få dem til at få vist nogle præstationsgevinster.

Mange gange har du kørt ind i CPU Ready, og det er svært at starte med at rette størrelsen på VM'er eller opgradere til processorer med flere kerner. Hvis du er i denne situation, kan du tilføje flere værter i din klynge med dette for at sprede belastningen på tværs af flere værter. Hvis du har værter med flere kerner / processorer end andre, kan også høje vCPU VM'er til disse højere kerneværter hjælpe. Du vil sikre din fysiske vært som har mindst det samme antal kerner, hvis ikke mere end VM'en, ellers vil det være meget langsomt / vanskeligt at planlægge overskydende vCPU til pCPU, da de skal låses på omtrent samme tid .

Endelig kan din hypervisor understøtte reservationer og begrænsninger på VM. Nogle gange bliver disse indstillet ved et uheld. Aggressive indstillinger på disse kan få CPU klar, når de underliggende ressourcer rent faktisk er tilgængelige. Det er normalt bedst at bruge reservationer og begrænser sparsomt og kun når det absolut er nødvendigt. For størstedelens vedkommende vil en korrekt størrelse klynge passende balancere ressourcer, og disse er typisk ikke nødvendige.

Sammenfattende er det bedste forsvar mod CPU Ready at vide, at det eksisterer og hvordan man kontrollerer det. Du kan derefter systematisk afgøre de bedste afbødningstrin for dit miljø givet ovenstående. Oplysningerne i denne artikel gælder for det meste universelt for enhver hypervisor, skønt skærmbilleder og diagrammer gælder specifikt for VMware.