CPU Ready: The Silent Hypervisor Killer

CPU Ready is iets waar u misschien nog niet bekend mee bent. Bij een eerste indruk lijkt het misschien een goede zaak, maar helaas is dat niet zo. CPU Ready heeft virtuele omgevingen langer teisteren dan we wisten wat het was. VMware definieert dit als het percentage van de tijd dat de virtuele machine gereed was, maar kon niet worden gepland om te worden uitgevoerd op de fysieke CPU. CPU Ready-tijd is afhankelijk van het aantal virtuele machines op de host en de CPU-belasting ervan. Hyper-V is pas onlangs begonnen met het leveren van deze teller (Hyper-V Hypervisor Virtual processor \ CPU wachttijd per verzending) en andere hypervisors bieden deze meetwaarde nog steeds niet.

Om te begrijpen wat CPU Ready is, moeten we begrijpen hoe hypervisors virtuele CPU's (vCPU) plannen in fysieke CPU's (pCPU). Wanneer vCPU-tijd nodig is in een VM, moeten vCPU ('s) worden gepland tegen pCPU (s) zodat de opdrachten / processen / threads tegen de pCPU kunnen worden uitgevoerd. In een ideale wereld zijn er geen bronconflicten of knelpunten als dit moet gebeuren. Wanneer een enkele vCPU-VM tijd moet plannen tegen een pCPU, is een pCPU-kern beschikbaar en is de CPU-gereedheid zeer minimaal in deze ideale wereld. Het is belangrijk op te merken dat CPU Ready altijd bestaat, maar in een ideale wereld is het zeer minimaal en niet opgemerkt.

In de echte wereld is een van de voordelen van virtualisatie dat je kunt wedden dat veel van je VM's niet al hun vCPU's tegelijk aanspreken en als het VM's met een zeer laag verbruik zijn, kun je zelfs raden hoeveel je kunt gebruiken laad uw fysieke host op op basis van CPU-gebruik en RAM-gebruik. In het verleden werden aanbevelingen gedaan om een verhouding van 4 vCPU tot 1 pCPU of zelfs 10: 1 te hebben, afhankelijk van de werklast. U kunt bijvoorbeeld een enkele quad-coreprocessor hebben maar elk een 4 VM's met vCPU's om u 16 vCPU's te geven tot 4 pCPU's of 4: 1. Wat ingenieurs echter begonnen te zien was dat de omgevingen gewoon verschrikkelijk traag waren en dat ze niet konden achterhalen waarom. RAM-gebruik leek goed, CPU-gebruik op de fysieke hosts kan zelfs erg laag zijn, minder dan 20%. De latentie bij opslag was extreem laag, maar de VM's waren extreem traag.

Wat er in dit scenario gebeurde, was CPU Ready. Er was een wachtrijopbouw van de vCPU klaar om te worden gepland, maar geen pCPU beschikbaar om tegen in te plannen. De hypervisor blokkeert de planning en veroorzaakt latentie voor de gast-VM. Het is een stille moordenaar die tot de laatste jaren niet veel gereedschappen kon detecteren. In een Windows VM zou het een eeuwigheid duren om op te starten en als het dan eindelijk wordt gedaan, wanneer je op het startmenu klikt, zou het een eeuwigheid duren om te verschijnen. Misschien klikt u er zelfs nog een keer op, in de veronderstelling dat het uw eerste klik niet accepteerde en wanneer het uiteindelijk inhaalt, krijgt u een dubbele klik. Op Linux kan je VM opstarten in de modus alleen-lezen of zelfs later het bestandssysteem overschakelen naar de alleen-lezen-modus.

Dus hoe bestrijden we CPU-gereed? Er zijn een paar manieren die kunnen helpen. De eerste is het bijhouden van CPU Ready-statistieken. In VMware wordt het niet aanbevolen om boven de 10% te gaan, maar in persoonlijke ervaring beginnen gebruikers boven de 5-7% te zien, afhankelijk van het type VM en wat het uitvoert.

Hieronder zal ik enkele voorbeelden van VMware ESXi 5.5 gebruiken om CPU gereed te tonen. Gebruik esxtop op de opdrachtregel. Druk op c voor CPU-weergave en u zou een kolom % RDY voor CPU gereed moeten zien. U kunt op hoofdletter V drukken voor weergave Alleen VM.

Hier ziet u dat% RDY enigszins hoog is voor een redelijk ongebruikte omgeving. In dit geval voert mijn ESXi 5.5 een test-VM uit bovenop VMware Fusion (Mac-hypervisor), dus het is naar verwachting een beetje aan het hoge eind sinds we een VM op een hypervisor uitvoeren bovenop een andere hypervisor.

In de vSphere-client kunt u de specifieke VM ophalen en op het tabblad Prestaties klikken. Vanaf daar klikt u op de kaartopties

PRO TIP: Als het probleem zich voordoet met uw computer of een laptop / notebook, kunt u proberen de Reimage Plus-software te gebruiken die de opslagplaatsen kan scannen en corrupte en ontbrekende bestanden kan vervangen. Dit werkt in de meeste gevallen, waar het probleem is ontstaan door een systeembeschadiging. U kunt Reimage Plus downloaden door hier te klikken

Selecteer in Kaartopties CPU, Realtime (als u vCenter heeft, heeft u mogelijk andere timingopties dan realtime). Selecteer Ready in de tellers. Mogelijk moet u de selectie van een andere teller ongedaan maken, omdat de weergave op dat moment slechts twee gegevenstypen toestaat.

U zult opmerken dat deze waarde een samenvatting is van gereed versus een percentage. Hier is een link naar een VMware KB-artikel over het converteren van de samengevatte metriek naar een percentage. - https://kb.vmware.com/kb/2002181

Bij het kopen van hardware verminderen meer cores de impact van CPU Ready. Hyperthreading helpt ook. Hyperthreading biedt geen volledige tweede kern voor elke primaire kern, maar meestal is dit voldoende om de vCPU naar pCPU te plannen en het probleem te verminderen. Hoewel hypervisors beginnen weg te gaan van de aanbeveling vCPU naar pCPU-ratio, kunt u meestal goed presteren in een matig gebruikte omgeving met een 4: 1 en vanaf daar gaan. Terwijl u begint met het laden van VM's, kijkt u naar CPU-wachttijd, CPU-gereed en algemeen gevoel en prestaties. Als u een aantal zwaar belaste VM's hebt, wilt u ze misschien op andere clusters scheiden en een lagere ratio gebruiken en ze licht houden. Aan de andere kant voor VM's waar prestaties niet belangrijk zijn en het is ok voor hen om traag te werken, kun je je veel sneller inschrijven.

Het op de juiste manier dimensioneren van de VM's is ook een enorm hulpmiddel om CPU Ready te bestrijden. Veel leveranciers bevelen specificaties goed aan over wat de VM mogelijk nodig heeft. Traditioneel zijn meer CPU's en meer kernen = meer vermogen. Het probleem in een virtuele omgeving is dat de hypervisor alle vCPU's naar pCPU's moet plannen op ongeveer dezelfde tijd en het vergrendelen van de pCPU's problematisch kan zijn. Als u een 8 VM VM hebt, moet u 8 pCPU's vergrendelen zodat ze tegelijkertijd kunnen plannen. Als uw vCPU-VM op enig moment slechts 10% van de totale vCPU's gebruikt, kunt u het vCPU-aantal beter terugbrengen tot 2 of 4. Het is beter om een VM uit te voeren met een CPU van 50-80% met minder vCPU's dan 10% bij meer vCPU's. Dit probleem is gedeeltelijk omdat de CPU-planner van het besturingssysteem zo ontworpen is dat zoveel mogelijk kernen worden gebruikt, maar als het is getraind om de kernen maximaal te maken voordat het meer gebruikt, is het misschien minder een probleem. Een te grote VM presteert mogelijk goed, maar kan een luidruchtige buur zijn voor andere VM's, dus het is meestal een proces waarbij u alle VM's in het cluster moet doorlopen om ze op de juiste grootte te zetten om prestatiewinst te zien.

Vaak ben je CPU Ready tegengekomen en is het moeilijk om VM's op de juiste maat te zetten of te upgraden naar processors met meer cores. Als u zich in deze situatie bevindt, kunt u hiermee meer hosts in uw cluster toevoegen om de belasting over meerdere hosts te verspreiden. Als u hosts met meer kernen / processors heeft dan andere, kan het helpen om hoge VMQU-VM's aan deze hogere core-hosts te koppelen. U wilt ervoor zorgen dat uw fysieke host minstens hetzelfde aantal kernen heeft als niet meer dan de VM, anders zal het erg traag / moeilijk zijn om het overschot van vCPU naar pCPU te plannen, omdat ze ongeveer op hetzelfde moment moeten worden vergrendeld .

Ten slotte kan uw hypervisor reserveringen en limieten voor de VM ondersteunen. Soms worden scripties per ongeluk ingesteld. Agressieve instellingen hiervan kunnen CPU-gereed maken, terwijl in feite de onderliggende bronnen ervoor beschikbaar zijn. Het is meestal het beste om reserveringen en limieten spaarzaam te gebruiken en alleen wanneer absoluut nodig. Grotendeels, zal een cluster van juiste grootte middelen behoorlijk in evenwicht brengen en deze zijn typisch niet nodig.

Samenvattend, de beste verdediging tegen CPU Ready is weten dat het bestaat en hoe je erop moet controleren. U kunt vervolgens, op basis van het bovenstaande, systematisch de beste risicostappen voor uw omgeving bepalen. Over het algemeen is de informatie in dit artikel universeel toepasbaar op elke hypervisor, hoewel de schermafbeeldingen en diagrammen specifiek van toepassing zijn op VMware.