CPU performance problemen VMware

[Metalfreak]

Wie o wie kan mij helpen met performance problemen op de virtuele omgeving op ons werk? Ik zal proberen zoveel mogelijk informatie in deze OP te verwerken.

Regelmatig door de dag merken we een vertraging op servers binnen de virtuele omgeving (vooral merkbaar op Terminal Servers). Dit zijn CPU gerelateerde problemen, binnen de VM is te zien dat er 100% CPU gebruikt wordt (niet echt aanwijsbaar één proces) en VMware geeft regelmatig een alert over hoog CPU gebruik van die machine. Ook is de algehele performance slecht gezien de resources die gebruikt worden. Voor de storage is er een NetApp aan gekoppeld en de bottleneck lijkt allemaal niet in het geheugen of de disks te zitten, volgens mij is het puur CPU gerelateerd.

Hardware:
2x Dell PowerEdge R900 met 24 cores.


1a. VMware Host 1 General


1b. VMware Host 2 General

Resources in gebruik midden op een dag:


2a. VMware Host 1 Resources


2b. VMware Host 2 Resources

Het lijkt er dus op dat ik nog resources genoeg over heb, maar dat deze niet optimaal gebruikt worden. Ik ben dus al wat op onderzoek uitgegaan en onder andere via deze blog: http://www.gabesvirtualwo...h-check/cpu-health-check/ een stuk wijzer geworden over het CPU gebruik van VMware systemen. Daar wordt ook aangegeven dat je een vuistregel kunt nemen van niet meer dan 6 vCPUs per fysieke core en daar zitten wij nog lang niet aan. Dan ben ik er dus weer verder in gedoken via de console met het commando esxtop en hier heb ik volgens mij wel één van de redenen van traagheid gevonden: de waarde voor %RDY is te hoog, wat betekent dat de CPU's te lang aan het wachten zijn tot er weer resources vrij zijn. Zie onderstaande screenshots:

Console esxtop screenshots


3a. esxtop VMware Host 1


3b. esxtop VMware Host 2

Nu is de grootste boosdoener (in 3b) wel een SQL server die we gauw weer terug gaan zetten naar een fysieke server omdat de performance niet voldoet, dus die zal komen te vervallen, maar de andere servers hebben ook een te hoge %RDY waarde. (dit was namelijk ook al het geval voordat die SQL server überhaupt maar bestond) Ik heb al geprobeerd om de prioriteit van de CPU shares voor de Terminal Servers te veranderen naar High, maar dit lijkt weinig verschil uit te maken.

Ik weet eerlijk gezegd niet waar ik het nu moet zoeken. Ik heb het document "Performance Best Practices for VMware vSphere 5.0" hier voor me liggen, maar tot nu toe nog weinig progressie geboekt. Wie heeft er tips hoe ik dit het beste aan kan pakken?

[Gardocki]

Hoeveel vCPU's/cores heb je totaal uitgegeven aan al je VM's?

Je kan het best even beginnen met het uitrekenen van de ratio tussen vCPU's tegenover de fysieke CPU's.
Als dat hoog is weet je gelijk dat het aantal fysieke CPU's/cores niet toereikend is.

[Metalfreak]

Gardocki schreef op dinsdag 11 juni 2013 @ 16:17:
Hoeveel vCPU's/cores heb je totaal uitgegeven aan al je VM's?

Dat is te zien in de laatste twee screenshots op de bovenste regel.

Host 1: 36 vCPUs
Host 2: 40 vCPUs

Wel heb ik dus maar 24 fysieke cores beschikbaar. Is dit dan echt te weinig? Als je naar resources kijkt (2a en 2b) zou ik toch nog wat over moeten hebben zou je zeggen.

[Gardocki]

Metalfreak schreef op dinsdag 11 juni 2013 @ 16:20:
[...]


Dat is te zien in de laatste twee screenshots op de bovenste regel.

Host 1: 36 vCPUs
Host 2: 40 vCPUs

Wel heb ik dus maar 24 fysieke cores beschikbaar. Is dit dan echt te weinig? Als je naar resources kijkt (2a en 2b) zou ik toch nog wat over moeten hebben zou je zeggen.

Ik zag het net ja, was al bezig met m'n post editten
Hoeveel machines heb je met 4 vCPU's/cores of meer?

[Metalfreak]

Gardocki schreef op dinsdag 11 juni 2013 @ 16:22:
[...]

Ik zag het net ja, was al bezig met m'n post editten
Hoeveel machines heb je met 4 vCPU's/cores of meer?

7 in totaal, 3x 2003 Terminal Servers en 4x 2008 Terminal servers en op dit moment dus nog één SQL Server, maar die gaat er dus uit volgende week. Nu was dit probleem er al voordat deze server live was.

[Gardocki]

Metalfreak schreef op dinsdag 11 juni 2013 @ 16:28:
[...]


7 in totaal, 3x 2003 Terminal Servers en 4x 2008 Terminal servers en op dit moment dus nog één SQL Server, maar die gaat er dus uit volgende week. Nu was dit probleem er al voordat deze server live was.

Als die machines met 4vCPU's een CPU cycle willen hebben van de VMware host "blokken" ze dus totaal 6 x 4 fysieke CPU's. Dus totaal 24 fysieke cores. Das best aan de hoge kant...

Als je al deze machines 2 vCPU's (of zelfs 1 vCPU) geeft zal de CPU ready waarde in je omgeving enorm omlaag gaan. En meeste machines zullen dan ook een stuk rapper gaan werken. Dit omdat ze eerder aan de beurt zijn op de fysieke CPU's.

[Andre_J]

Kijk in vmware naar de performance per Vm.
Je kan dan makkelijk zien of je het aantal vcpu's te hoog hebt in geschat door naar de CPU history te kijken.
Wij hadden het zelfde met onze 2008r2 ts machines, die draaien nu met "maar" 2 vcpu tov de 4 voorheen.

[Metalfreak]

Gardocki schreef op dinsdag 11 juni 2013 @ 16:56:
[...]

Als die machines met 4vCPU's een CPU cycle willen hebben van de VMware host "blokken" ze dus totaal 6 x 4 fysieke CPU's. Dus totaal 24 fysieke cores. Das best aan de hoge kant...

Als je al deze machines 2 vCPU's (of zelfs 1 vCPU) geeft zal de CPU ready waarde in je omgeving enorm omlaag gaan. En meeste machines zullen dan ook een stuk rapper gaan werken. Dit omdat ze eerder aan de beurt zijn op de fysieke CPU's.

Hier ga ik eens kritisch naar kijken. Volgens mij denk ik nog teveel in fysieke machines, maar als ik het goed begrijp heeft het toewijzen van meerdere cores aan een VM alleen zin als je ook echt multi-core applicaties draait? Op een Terminal Server zou het dan toch wel nut hebben, aangezien die veel processen draait, of denk ik nu verkeerd?

Maar als ik het goed begrijp wil het dus zeggen dat 2 vCPUs niet krachtiger hoeven te zijn dan 1 vCPU, maar heeft dit alleen met de verdeling binnen het OS in de VM te maken?

[Question Mark]

Metalfreak schreef op woensdag 12 juni 2013 @ 08:40:
[...]
Op een Terminal Server zou het dan toch wel nut hebben, aangezien die veel processen draait, of denk ik nu verkeerd?

Kijk ook even goed naar de schaalbaarheid van Terminal Servers, die schalen qua cpu-load niet lineair... Je kunt beter veel kleinere Terminal Servers hebben met bv 2 (v)cpu's, dan enkele grote zware machines...

[3DDude]

Even andere insteek:

*mij lijkt het namelijk dat die boel rap zat is voor hetgeen wat je wilt draaien, maar thats just me*

Ik heb ooit van me werk een server van NEC gehad, die kon via de firmware van die server uitlezen dat er iets was met de CPU - die was gewoon gaar/niet goed.En ik weet nog dat we een nieuwe CPU kregen opgestuurd om de oude te vervangen...

Heb jij met Dell ook al de nodige monitoring tools, temperaturen, statussen en grappen bekeken?

Misschien de moeite waard om dat te doen?

[ Voor 7% gewijzigd door 3DDude op 14-06-2013 22:18 ]

[Question Mark]

3DDude schreef op vrijdag 14 juni 2013 @ 22:17:
*mij lijkt het namelijk dat die boel rap zat is voor hetgeen wat je wilt draaien, maar thats just me*

En waar basseer je dat op?

ESXTop laat zien dat het percentage CPU-ready te hoog is (en da's simpelweg gesteld de tijd hoelang een vm moet wachten op cpu-tijd van de scheduler). Dat wordt in 99,99% van alle gevallen veroorzaakt door te weinig beschikbare cores... Gardocki in "CPU performance problemen WMware" legt het al redelijk uit.

Edit:

Hier nog een hele mooie link die het helder uitlegt:

The VMware Virtual CPU Dilemma - Overprovisioning vCPU to pCPU ratios

[ Voor 19% gewijzigd door Question Mark op 15-06-2013 00:00 ]

[3DDude]

Question Mark schreef op vrijdag 14 juni 2013 @ 22:38:
[...]
En waar basseer je dat op?

ESXTop laat zien dat het percentage CPU-ready te hoog is (en da's simpelweg gesteld de tijd hoelang een vm moet wachten op cpu-tijd van de scheduler). Dat wordt in 99,99% van alle gevallen veroorzaakt door te weinig beschikbare cores... Gardocki in "CPU performance problemen WMware" legt het al redelijk uit.

*ok, ik geef toe, dat was natte vinger werk *

Anyway Waarom maak je niet een lijstje met hoeveel cores je hebt, en hoeveel VM's cores je hebt uitgedeeld.
Ik zou sowieso die TS servers gewoon max 2 Vcores geven (waarom heeft zo'n ding er 4 nodig.. gebruikt die dat ook echt dan?)

Verder heb je 24 logical processors --> maar geen HT? why? Is het spul zo oud dat dat niet ondersteund wordt.. *of ben ik scheel en kijk ik fout * Nevermind me again - ik zie dat die Xeon proc geen eens hyperthreading support (cpu uit 2008... hmm)

p.s. TS je draait dus gewoon op best wel oude meuk 2008 zijn die procs uit man kom op 2008 + 5 jaar = hey 2013

[ Voor 10% gewijzigd door 3DDude op 14-06-2013 23:31 ]

[Yarisken]

Je hebt wel een pak cpu verbruik op die ene server ( 32000 Mhz bijna ). Dat haal ik nooit op onze productie machines.
Ik schat dat je misschien best nog een extra server erbij zet. Dat hoeft geen nieuwe te zijn.
Ik heb bv een virtuele server met crappy software die 4 vcpu's constant op 80 - 90 % zet. Deze server heb ik dan op een oudere fysieke server geplaatst met esxi free. Ok ik heb dan geen "vmotion" maar met een trukje kan je makkelijk deze server toch overfailen naar een productie server als het misgaat ( wel niet live ).
Ik heb ook een server bv die enorm veel I/O genereert en die draait dan op lokale sas-storage. Anders krijg ik teveel "write latency" op mijn netapp.
Voort uiteraard ook je vpcu's beter scalen. Ik begin elke server met 1vcpu en steek enkel bij indien nodig.

Succes

[Metalfreak]

3DDude schreef op vrijdag 14 juni 2013 @ 22:44:
[...]


*ok, ik geef toe, dat was natte vinger werk *

Anyway Waarom maak je niet een lijstje met hoeveel cores je hebt, en hoeveel VM's cores je hebt uitgedeeld.
Ik zou sowieso die TS servers gewoon max 2 Vcores geven (waarom heeft zo'n ding er 4 nodig.. gebruikt die dat ook echt dan?)

Ja, minder moet ik ze echt niet geven, dan beginnen mensen heel hard te stuiteren.

Verder heb je 24 logical processors --> maar geen HT? why? Is het spul zo oud dat dat niet ondersteund wordt.. *of ben ik scheel en kijk ik fout * Nevermind me again - ik zie dat die Xeon proc geen eens hyperthreading support (cpu uit 2008... hmm)

p.s. TS je draait dus gewoon op best wel oude meuk 2008 zijn die procs uit man kom op 2008 + 5 jaar = hey 2013

Als het goed is, komen de machines uit begin 2010, dus dat valt nog wel mee. In theorie zou het snel genoeg moeten zijn.

We zijn trouwens wel al wijzer, niet alleen onze CPU performance komt tekort, maar onze netwerkperformance is ook dramatisch te noemen. We hebben vanalles getest, maar krijgen zelfs binnen onze localhost vaak geen hogere snelheden dan 100 Mbit en dan gaat het netwerkverkeer nog niet eens naar buiten. Ook getest met een nieuw netwerk binnen VMware voor twee servers en deze op dezelfde host verkeer naar elkaar laten sturen. De snelheid is dramatisch te noemen. Daarbij maakt het overigens niets uit welke host het is. We lagen wel nog wat updates achter voor ESXi, deze zijn nu ook geïnstalleerd en het lijkt een heel klein beetje beter te zijn, maar ik word er nog niet helemaal vrolijk van.

[Question Mark]

Metalfreak schreef op maandag 17 juni 2013 @ 08:39:
[...]
Ja, minder moet ik ze echt niet geven, dan beginnen mensen heel hard te stuiteren.

De oplossing is dan om meerdere kleinere terminal servers neer te zetten.

[TMDevil]

Metalfreak schreef op maandag 17 juni 2013 @ 08:39:
[...]
We zijn trouwens wel al wijzer, niet alleen onze CPU performance komt tekort, maar onze netwerkperformance is ook dramatisch te noemen. We hebben vanalles getest, maar krijgen zelfs binnen onze localhost vaak geen hogere snelheden dan 100 Mbit en dan gaat het netwerkverkeer nog niet eens naar buiten. Ook getest met een nieuw netwerk binnen VMware voor twee servers en deze op dezelfde host verkeer naar elkaar laten sturen. De snelheid is dramatisch te noemen. Daarbij maakt het overigens niets uit welke host het is. We lagen wel nog wat updates achter voor ESXi, deze zijn nu ook geïnstalleerd en het lijkt een heel klein beetje beter te zijn, maar ik word er nog niet helemaal vrolijk van.

Hou er rekening mee dat je voor NIC performance ook CPU nodig hebt. Dezelfde CPU als die je voor je VM's gebruikt.
Ik zou beginnen met al je VM's terug te brengen naar 2 cores (en als het even kan zelfs naar 1). Hebben ze dan echt meer nodig, dan kan je ze er 3 geven.

Een plaatje van het effect kan zijn:


De bovenste is van één van de servers die die ESX (overigens geen 3.5). Je ziet met name dat de kernel usage verminderd is, wat gewoon kwam doordat die machine stond te wachten. Het onderste plaatje is de load op de ESX machine die is afgenomen.

[Oid]

kwam deze tegen op linkedin, misschien handige informatie voor jullie organisatie wbt VMware gebruik http://www.joshodgers.com...ne-performance-cpu-ready/