CPU Ready är något som 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 'Procent av tid som den virtuella maskinen var redo, men kunde inte få schemalagd körning på den fysiska processorn. CPU Ready-tid beror på antalet virtuella maskiner på värden och deras CPU-belastningar. ” Hyper-V började nyligen tillhandahålla denna räknare (Hyper-V Hypervisor Virtual processor CPU Väntetid per leverans) och andra hypervisorer kan fortfarande inte tillhandahålla detta mått.
För att förstå vad CPU Ready är måste vi förstå hur hypervisor schemalägger virtuella CPU: er (vCPU) till fysiska CPU: er (pCPU). När vCPU-tid behövs i en virtuell dator måste vCPU (ar) planeras mot pCPU (er) så att kommandona / processerna / trådarna kan köras mot pCPU: n. I en idealisk värld finns det inga resurskonflikter eller flaskhalsar när detta behöver ske. När en enskild vCPU VM behöver schemalägga tid mot en pCPU är en pCPU-kärna tillgänglig och CPU Ready är mycket minimal i den här idealiska världen. Det är viktigt att notera att CPU Ready alltid finns men i en idealisk värld är det mycket minimalt 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 virtuella datorer inte kommer att spika alla sina vCPU: er samtidigt och om de är mycket användbara virtuella datorer kan du till och med gissa på 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 en 4 vCPU till 1 pCPU eller till och med 10: 1 beroende på arbetsbelastning. Du kan till exempel ha en enda fyrkärnig processor men har fyra virtuella datorer med vCPU vardera för att ge dig 16 vCPU till 4 pCPU eller 4: 1. Vad ingenjörer började se är dock att miljöerna bara var väldigt långsamma och att de inte kunde ta reda på varför. RAM-användning verkade bra, CPU-användningen på de fysiska värdarna kan till och med vara mycket låg, under 20%. Lagringsfördröjningen var extremt låg, men de virtuella datorerna var extremt tröga.
Vad som hände i detta scenario var CPU Ready. Det fanns en köuppbyggnad av vCPU redo att planeras men ingen pCPU tillgänglig att schemalägga mot. Hypervisor skulle stoppa schemaläggningen och orsaka latens för gäst-VM. Det är en tyst mördare som fram till de senaste åren fanns det inte många verktyg att upptäcka. I en virtuell Windows-dator skulle det ta evigt att starta och sedan när det äntligen gör det, när du klickar på startmenyn, tar det evigt att dyka upp. Du kan till och med klicka på den igen och tänka att den inte accepterade ditt första klick och när det äntligen kommer ikapp får du ett dubbelklick. På Linux kan din virtuella dator starta upp i skrivskyddat läge eller till och med byta filsystem till skrivskyddat lä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 är övervakning av CPU-klara mätvärden. I VMware rekommenderas det inte att gå över 10% men i personlig upplevelse börjar användare märka över 5-7% beroende på vilken typ av virtuell dator och vad den kör.
Nedan kommer jag att använda några exempel från VMware ESXi 5.5 för att visa CPU Ready. Kör “esxtop” med hjälp av kommandoraden. Tryck på 'c' för CPU-vyn så visas en kolumn ' % RDY ”För CPU Ready. Du kan trycka på ' V ”För Endast VM-vy.
Här kan du se att% RDY är något högt för en ganska oanvänd miljö. I det här fallet kör min ESXi 5.5 en test-VM ovanpå VMware Fusion (Mac hypervisor) så det förväntas vara lite i high end eftersom vi kör en VM på en hypervisor ovanpå en annan hypervisor.
I vSphere-klienten kan du dra upp den specifika virtuella datorn och klicka på fliken Prestanda. Därifrån klickar du på 'Diagramalternativ'
Välj CPU, Realtid i diagramalternativ (om du har vCenter kan du ha andra tidsalternativ än realtid). Därifrån i Counters väljer du 'Ready'. Du kan behöva avmarkera en annan räknare eftersom vyn endast tillåter två datatyper vid varje given tidpunkt.
Du kommer att notera att detta värde är en sammanfattning av redo kontra procent. Här är en länk till en VMware KB-artikel om hur man konverterar de sammanfattade mätvärdena till en procentsats. - https://kb.vmware.com/kb/2002181
När du köper hårdvara hjälper fler kärnor att minska effekten av CPU Ready. Hypertrådning hjälper också. Medan hypertrådning inte ger en fullständig andra kärna för varje primär kärna, är det vanligtvis tillräckligt för att tillåta schemaläggning av vCPU till pCPU och hjälpa till att mildra problemet. Även om hypervisorer börjar flytta från rekommendation av vCPU till pCPU-förhållande, kan du vanligtvis göra det bra i en måttligt använd miljö med en 4: 1 och gå därifrån. När du börjar ladda virtuella datorer, titta på CPU-latens, CPU-klar och övergripande känsla och prestanda. Om du har några kraftiga virtuella datorer, kanske du vill separera dem på andra kluster och använda ett lägre förhållande och hålla dem lätta. Å andra sidan för virtuella datorer där prestanda inte är nyckeln och det är ok för dem att köra trögt kan du överprenumerera mycket högre.
Att dimensionera de virtuella datorerna på rätt sätt är också ett stort verktyg för att bekämpa CPU Ready. Många leverantörer rekommenderar specifikationer över vad den virtuella datorn faktiskt kan behöva. Traditionellt fler processorer och fler kärnor = mer kraft. Problemet i en virtuell miljö är att hypervisoren måste schemalägga alla vCPU: er till pCPUs ungefär samtidigt och att låsa pCPU: erna kan vara problematiska. Om du har en 8 vCPU VM måste du låsa 8 pCPU så att de kan schemalägga samtidigt. Om din vCPU VM bara använder 10% av totala vCPU: er vid varje given tidpunkt, är det bättre att du tar ner vCPU-räkningen till 2 eller 4. Det är bättre att köra en virtuell dator vid 50-80% CPU med mindre vCPU än 10% vid fler vCPU: er. Det här 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 tränades för att maximera kärnor innan du använder mer kan det vara mindre problem. En överdimensionerad virtuell dator kan fungera bra men kan vara en 'bullrig granne' för andra virtuella datorer, så det är vanligtvis en process där du måste gå igenom alla virtuella datorer i klustret för att 'rätt storlek' dem för att se vissa prestationsvinster.
Många gånger har du stött på CPU Ready och det är svårt att starta rätt storlek på virtuella datorer eller uppgradera till processorer med fler kärnor. Om du befinner dig i den här situationen kan du lägga till fler värdar i ditt kluster för att sprida belastningen över fler värdar. Om du har värdar med fler kärnor / processorer än andra kan det också hjälpa att koppla höga vCPU-virtuella datorer till dessa högre kärnvärdar. Du vill säkerställa att din fysiska värd har åtminstone samma antal kärnor om inte mer än den virtuella datorn, annars blir det väldigt långsamt / svårt att schemalägga överskottet av vCPU till pCPU eftersom de måste spärras ungefär samtidigt .
Slutligen kan din hypervisor stödja reservationer och begränsningar för den virtuella datorn. Ibland ställs uppsatser av misstag. Aggressiva inställningar på dessa kan leda till att CPU är redo när faktiskt de underliggande resurserna är tillgängliga för det. Det är oftast bäst att använda reservationer och begränsningar sparsamt och bara när det är absolut nödvändigt. För det mesta balanserar ett kluster med rätt storlek korrekt resurser och dessa behövs vanligtvis inte.
Sammanfattningsvis är det bästa försvaret mot CPU Ready att veta att det finns och hur man kontrollerar det. Du kan sedan systematiskt bestämma de bästa lindringsstegen för din miljö med tanke på ovanstående. För det mesta gäller informationen i den här artikeln universellt för alla hypervisor, även om skärmdumpar och diagram gäller specifikt för VMware.
5 minuter läst
