[ESX 4.0] CPU performance

[MuadD1b]

Heren,

We zitten met een probleempje in onze virtuele omgeving.
De ESX servers hebben 2 quadcore CPU's zonder hyperthreading. En toch kunnen onze virtuele machines niet meer dan 1 cpu tegelijk aanspreken. Tijdens het draaien van stress tests zien we dit het OS altijd slechts 1 cpu gebruikt. Het OS wisselt om de paar seconden van cpu.

Voorbeeldje:
Superpi in Windows 2008 x64. Na het starten van de test begint het systeem bij CPU0, deze cpu staat 5-10 seconden op 100% te stampen terwijl de 3 andere cpus idle zijn. Na 5-10 seconden switcht het systeem naar de volgende CPU. Enz enz enz.

Er zitten geen limitaties op de resource pools waar de servers in zitten. Het gedrag is op meerdere OS'en gelijk. Zowel x86 als x64 (linux en windows). Het totale CPU gebruik van de ESX servers zit niet boven de 20%.
Op dit moment is een server met 1 cpu zelfs sneller dan een server met 4 cpu's.
iemand enig idee waar dit gedrag vandaan kan komen?

Groeten!

[bigfoot1942]

start superpi een 2e keer en draai m parallel... of is superpi al multithreaded?

[Gardocki]

En draai je superpi op 1 machine, of op meerdere machines tegelijk?

[MuadD1b]

Een instance van superpi gebruikt met gemak 4 CPU's op 100% in een normale omgeving.
Overigens is het niet alleen Superpi waar het fout gaat. De VM's kunnen uberhaupt niet meer dan 1 core/cpu tegelijk aanspreken. Zowel in Windows 2003/2008 als Ubuntu server 11.04.
De fysieke CPU's van de ESX servers voeren geen knoop uit en komen niet boven de 20% usage.

[Voor 14% gewijzigd door MuadD1b op 20-06-2011 08:11]

[Teutlepel]

Hoeveel vCPU's heeft elke VM? 8 neem ik aan?

[bigfoot1942]

Teutlepel schreef op maandag 20 juni 2011 @ 09:37:
Hoeveel vCPU's heeft elke VM? 8 neem ik aan?

pfff, als je een dikke performance penalty wilt moet je dat doen.
dat wordt echt een uitdaging voor de CPU scheduler...

[mindcre8r]

Als je bij het aanmaken van de VM aangaf dat ie 1 CPU heeft gebruikt ie er niet meer dan 1. (toch?)
Welke licentie heb je aan je server geknoopt?

[Voor 19% gewijzigd door mindcre8r op 13-07-2011 17:35]

[denpowel]

Hoeveel vm's heb je draaien op 1 host ?
En hoe is de cpu verdeling host/guest?
Als je veel quad core vm's hebt kan je het de scheduler moeilijk maken en zal de performance slecht zijn...
Er moeten namelijk 4 cores tegelijk vrij zijn om een instructie door te voeren.


Welke super i gebruik je ?
Standaard super pi gaat maar 1 core belasten.
Je kan ook super pi mod gebruiken (google)
Deze kan meerdere core's te gelijk belasten.
(je machine kan dan wel freezed lijken).

gtz
denpowel

[Wirehead]

denpowel schreef op woensdag 20 juli 2011 @ 09:28:
Hoeveel vm's heb je draaien op 1 host ?
En hoe is de cpu verdeling host/guest?
Als je veel quad core vm's hebt kan je het de scheduler moeilijk maken en zal de performance slecht zijn...
Er moeten namelijk 4 cores tegelijk vrij zijn om een instructie door te voeren.

Inderdaad hierop verderzoeken..
Indien je bvb een 2 core machine hebt; dan moet de VM wachten tot er 2 cores (fysiek) beschikbaar zijn.. En raar maar waar: een 2-core machine kan in een VM dus effectief trager zijn dan 1 singlecore. Dit omdat de kans dat 1 core vrij is voor verwerking groter is dan 2 cores tegelijkertijd idle.

Bij een VM omgeving is het dus beter om 2x1CPU VM op te zetten dan 1x2CPU VM - meer gaan richten op clustered apps e.d.

[RPSimon]

Wirehead schreef op woensdag 20 juli 2011 @ 11:44:
[...]


Inderdaad hierop verderzoeken..
Indien je bvb een 2 core machine hebt; dan moet de VM wachten tot er 2 cores (fysiek) beschikbaar zijn.. En raar maar waar: een 2-core machine kan in een VM dus effectief trager zijn dan 1 singlecore. Dit omdat de kans dat 1 core vrij is voor verwerking groter is dan 2 cores tegelijkertijd idle.

Bij een VM omgeving is het dus beter om 2x1CPU VM op te zetten dan 1x2CPU VM - meer gaan richten op clustered apps e.d.

Ja inderdaad, de wachttijden voor de toewijzing van processing-time van VM met meerdere vCPU's kunnen hoog oplopen. Er moeten twee ( of het aantal vCPU ) core's op hetzelfde moment vrij zijn voor hij tijd krijgt op de CPU. Dat is dus géén goed idee. Het is inderdaad beter enkele kleinere VM's met 1 vCPU dan een mega VM met 8 vCPU.

Heb je veel multi vCPU VM's? Wat je ook eens moet doen in inloggen op de console van vm en daar een het commando esxtop laten lopen. Daar moet je eens kijken of er niet te veel processen in wacht staan op kernel-time. Je kan daar ook zien of de CPU gewoon niet te veel moet wachten op I/O en dat de vm's daarom geen processing-time krijgt...