CPU Ready: The Silent Hypervisor Killer

CPU Ready är något du kanske inte känner till. Vid ett första intryck kan det låta som en bra sak men tyvärr är det inte. CPU Ready har plågat virtuella miljöer längre än vi visste vad det var. VMware definierar detta som den procentandel av tiden som den virtuella maskinen var klar men kunde inte schemaläggas att köras på den fysiska CPU. CPU Ready Time är beroende av antalet virtuella maskiner på värden och deras CPU-belastningar. Hyper-V har nyligen börjat tillhandahålla denna räknare (Hyper-V Hypervisor Virtual Processor \ CPU-väntetid per avsändning) och andra hypervisorer kan fortfarande inte ge denna mätvärde.

För att förstå vad CPU Ready ska vi förstå hur hypervisorer schema virtuella CPU (vCPU) till fysiska processorer (pCPU). När vCPU-tid behövs i en VM, måste vCPU (er) schemaläggas mot pCPU (er) så att kommandon / processer / trådar kan köra mot pCPU. I en ideal värld finns det inga resurskonflikter eller flaskhalsar när detta behöver hända. När en enda vCPU VM behöver schemalägga tid mot en pCPU, är en pCPU-kärna tillgänglig och CPU Ready är väldigt minimal i den här idealvärlden. Det är viktigt att notera att CPU Ready alltid existerar men i en ideal värld är det mycket minimal och inte märkt.

I den verkliga världen är en av fördelarna med virtualisering att du kan satsa på att många av dina VM inte kommer att pigga alla sina vCPUs samtidigt, och om de är mycket låga användningsvM, kan du till och med göra gissningar om hur mycket du kan ladda upp din fysiska värd baserat på CPU-användning och RAM-användning. Tidigare gjordes rekommendationer om att ha ett 4 vCPU till 1 pCPU eller till och med 10: 1-förhållandet beroende på arbetsbelastning. Du kan till exempel ha en enstaka quad core-processor men har en 4 VM med vCPUs för att ge dig 16 vCPU till 4 pCPU eller 4: 1. Vilka ingenjörer började se är att miljöerna var bara fruktansvärt långsamma och de kunde inte räkna ut varför. RAM-användningen verkade bra, CPU-användningen på de fysiska värdena kan till och med vara mycket låg, under 20%. Lagrings latens var extremt låg, men VM: erna var extremt tröga.

Vad som hände i detta scenario var CPU Ready. Det var en köuppbyggnad av vCPU redo att vara schemalagd men ingen pCPU tillgänglig att schemalägga mot. Hypervisören skulle stoppa schemaläggningen och orsaka latens för gästens VM. Det är en tyst mördare som fram till senare år inte fanns många verktyg att upptäcka. I en Windows VM, skulle det ta för evigt att starta och då när det äntligen gör, när du klickar på startmenyn, skulle det ta för evigt att dyka upp. Du kanske till och med klickar på det igen och tror att det inte accepterade ditt första klick och när det äntligen hamnar får du ett dubbelklick. På Linux kan din VM starta upp i läsningsläge eller till och med byta filsystem till läsningsläge någon gång senare.

Så hur bekämpar vi CPU Ready? Det finns några sätt som kan hjälpa till. Först övervakar CPU Ready-mätvärdena. I VMware rekommenderas det inte att gå över 10%, men i personlig erfarenhet börjar användarna att märka över 5-7% beroende på vilken typ av VM och vad den körs.

Nedan kommer jag att använda några exempel från VMware ESXi 5.5 för att visa CPU Ready. Använd kommandoraden, kör esxtop. Tryck c för CPU-vy och du bör se en kolumn % RDY för CPU Ready. Du kan trycka på Kapitel V för VM Only View.

Här kan du se att% RDY är något hög för en ganska oanvänd miljö. I det här fallet kör min ESXi 5.5 ett test VM på toppen av VMware Fusion (Mac hypervisor) så det förväntas vara lite i high end eftersom vi kör en VM på hypervisor ovanpå en annan hypervisor.

I vSphere-klienten kan du dra upp den specifika VM och klicka på fliken Prestanda. Därifrån klickar du på diagramalternativen

Inom diagramalternativ väljer du CPU, Realtid (om du har vCenter kan du ha andra tidsalternativ än realtid). Därifrån i räknaren väljer du Klar. Du kan behöva avmarkera en annan räknare eftersom vyn endast tillåter två datatyper vid en viss tidpunkt.

Du kommer att notera att detta värde är en sammanfattning av redo mot en procentandel. Här är en länk till en artikel i VMware KB om hur du omvandlar de sammanfattade metriska värdena till en procentandel. - https://kb.vmware.com/kb/2002181

När du köper hårdvara hjälper fler kärnor att minska effekten av CPU Ready. Hyperthreading hjälper också. Medan Hyperthreading inte ger en fullständig andra kärna för varje primärkärna, är det vanligtvis tillräckligt för att tillåta schemaläggning av vCPU till pCPU och bidra till att mildra problemet. Även om hypervisorer börjar röra sig från vCPU till pCPU-förhållande, kan du vanligtvis göra det bra i en måttligt använd miljö med 4: 1 och gå därifrån. När du börjar ladda VM ser du på CPU-latens, CPU Ready och övergripande känsla och prestanda. Om du har några tunga slående VM, kanske du vill segregera dem på andra kluster och använda ett lägre förhållande och hålla dem lätta. Å andra sidan för VM där prestanda inte är nyckel och det är ok för dem att köra trögt kan du över prenumerera mycket högre.

Storleksanpassning av VM: erna är också ett stort verktyg för att bekämpa CPU Ready. Många leverantörer rekommenderar specifikationerna väl över vad VM faktiskt behöver. Traditionellt fler processorer och fler kärnor = mer kraft. Problemet i en virtuell miljö är att hypervisorn måste schemalägga alla vCPU: erna till pCPUs ungefär samtidigt och låsning av pCPU: erna kan vara problematisk. Om du har en 8 vCPU VM måste du låsa 8 pCPU-enheter så att de kan schemaläggas samtidigt. Om din vCPU VM bara använder 10% av de totala vCPU: erna vid varje tillfälle, är det bättre att få vCPU-räkningen till 2 eller 4. Det är bättre att köra en VM vid 50-80% CPU med mindre vCPU än 10% vid fler vCPUs. Problemet beror delvis på att operativsystemets CPU-schemaläggare är utformad för att använda så många kärnor som möjligt, men om det utbildades till max-kärnor innan du använder mer kan det vara mindre av ett problem. En överdimensionerad VM kan fungera bra men kan vara en bullrig granne för andra VM så det är vanligtvis en process där du måste gå igenom alla VM i klustret för att få dem rätt för att se några prestationsvinster.

Många gånger har du stött på CPU Ready och det är svårt att starta rätt storlek på VM eller uppgradera till processorer med fler kärnor. Om du befinner dig i denna situation kan du lägga till fler värdar i ditt kluster för att sprida belastningen på flera värdar. Om du har värdar med fler kärnor / processorer än andra kan det vara bra att bära höga VCPU VM till dessa högre kärnvärdar. Du vill säkerställa din fysiska värd som har minst samma antal kärnor om inte mer än VM, annars kommer det att vara mycket långsamt / svårt att schemalägga överskottet av vCPU till pCPU eftersom de måste låsas ungefär samtidigt .

Slutligen kan din hypervisor stödja reservationer och begränsningar på VM. Ibland blir dessa av misstag inställda. Aggressiva inställningar på dessa kan leda till att processorn är klar när de underliggande resurserna är tillgängliga för den. Det är vanligtvis bäst att använda reservationer och begränsar sparsamt och endast när det absolut behövs. För det mesta, en korrekt storlek kluster på lämpligt sätt balansera resurser och dessa är vanligtvis inte behövs.

Sammanfattningsvis vet det bästa försvaret mot CPU Ready att det existerar och hur man kontrollerar det. Du kan sedan systematiskt bestämma de bästa reduceringsstegen för din miljö med tanke på ovanstående. För det mesta gäller informationen i denna artikel universellt för någon hypervisor, även om skärmdumparna och diagrammen gäller specifikt för VMware.

PRO TIPS: Om problemet är med din dator eller en bärbar dator, bör du försöka använda Reimage Plus-programvaran som kan skanna förvaret och ersätta korrupta och saknade filer. Detta fungerar i de flesta fall där problemet uppstått på grund av systemkorruption. Du kan ladda ner Reimage Plus genom att klicka här