vSphere 5.0 Guest CPU en relatie host CPU gebruik.

[kwiebus]

Ik zit met het volgende:

vSphere ESXi 5.0 (Essentials) host met 2 sockets, 6 cores per socket, 24 logical processors.

Er draaien op dit moment 11 guests op deze host. De totale CPU belasting komt volgens de performance grafiek in de vSphere client normaal niet boven de 10% uit en ligt het grootste deel van de tijd onder de 5%.

Als ik op een W2k8 R2 guest een single threaded proces draai wat één vcpu CPU voor 100% belast dan gaat de CPU belasting van de host naar maximaal zo'n 10%.

Ik heb van alles zitten te proberen met resource pools, shares en reservations maar het lukt mij niet om bij een single threaded proces dat één vcpu van een guest 100% belast de host CPU meer dan zo'n 10% te belasten.

De vraag is nu hoe ik er voor kan zorgen dat een single threaded proces op een guest meer CPU krijgt zodat deze sneller tot een eind kan komen?

[Dennism]

Een Core blijft voor zover ik weet een core. Ik weet niet of VMware een ht core als volwaardige core rekent, maar als dat zo is begrijp ik wel dat een single vcpu maar een paar procent belasting geeft op het geheel (4.1xx% als een HT core volledig gerekend wordt, 8,3xx% als een HT core niet meegerekend zou worden).

Als het goed is kun je ook zien hoeveel Mhz een bepaalde VM gebruikt. Misschien is het handig dit eens naast het aantal Mhz van 1 fysieke core te leggen. Als dit overeenkomt dan wordt 1 vCpu volledig belast en kan je volgens mij alleen versnellen dooor multithreading (meer vCpu's) toe te passen.

[ Voor 8% gewijzigd door Dennism op 06-09-2013 00:16 ]

[Wim-Bart]

Daarnaast moet je beseffen dat W2K8 (R2) met 1 core totaal niet schaalt qua performance en je extreem te maken krijgt met processor wait queues. Wanneer je 2 cores toe wijst zal je zien dat je de boel wel omhoog gaat krijgen.

[squaddie]

In ESX is de processor vrijwel niet gevirtualiseerd, wat inhoud dat maximum prestaties van de virtuele processor gelijk zijn aan de maximum prestaties van een fysieke core van de processor en kent ook dezelfde beperkingen. Er worden helaas geen meerdere fysieke cores samengevoegd tot een virtuele snellere processor. VMware zou een leuke som geld voor over hebben om een technologie in handen te krijgen om bijvoorbeeld meerdere 2.5 Ghz cores samen te voegen tot een 10 Ghz virtuele processor met vrijwel lineaire schaling. Helaas is dit met de huidige architectuur tot op heden niet mogelijk gebleken.

Wil je dat single threaded proces sneller laten verlopen kan je een tweede cpu toekennen aan de VM zodat dit proces een "eigen" cpu kan claimen, maar in mijn ervaring is de winst vrij beperkt op een kale Windows 2008 R2 VM. Andere optie is snellere processoren kopen ofwel als je nu 2.5 Ghz hebt bijvoorbeeld 3 Ghz processors kopen. De derde optie is wachten op ESXi 5.5, deze heeft betere mogelijkheden gekregen om de turbo modes van processoren te benutten. De laatste optie is de software ontwikkelaar vragen zijn applicatie om te bouwen naar multi threaded proces.

Ter info; Resource pools, shares en reserveringen zijn kort door bocht genomen bedoeld als de scheduler van ESX onvoldoende resources heeft om aan alle vraag te kunnen voldoen een VM of groep VMs prioriteit te geven over de andere VMs.

[kwiebus]

squaddie schreef op vrijdag 06 september 2013 @ 09:50:
Wil je dat single threaded proces sneller laten verlopen kan je een tweede cpu toekennen aan de VM zodat dit proces een "eigen" cpu kan claimen, maar in mijn ervaring is de winst vrij beperkt op een kale Windows 2008 R2 VM.

De guest heeft al meerdere vcpu en het single threaded maakt gebruik van maar 1 cpu van de guest. Dus als de guest 2 vcpu heeft dan is de CPU load op de guest bij het draaien van een single threaded proces 50%.

Zou het ook nog wat uit kunnen maken als ik op de host hyper threading uitzet?

[squaddie]

Het is onwaarschijnlijk dat het uitschakelen van hyper threading de performance verbeterd. Hyper treading is primair een techniek om de reken-eenheden van de processor beter te benutten. Overigens zijn er wel situaties waarin hyper treading negatieve invloed heeft op de performance, maar ik acht het onwaarschijnlijk dat dit van toepassing is op jouw host.

[Dennism]

kwiebus schreef op vrijdag 06 september 2013 @ 14:00:
[...]

De guest heeft al meerdere vcpu en het single threaded maakt gebruik van maar 1 cpu van de guest. Dus als de guest 2 vcpu heeft dan is de CPU load op de guest bij het draaien van een single threaded proces 50%.

Zou het ook nog wat uit kunnen maken als ik op de host hyper threading uitzet?

Dit zou in deze situatie dan ook gewoon kloppen. Single threaded kan natuurlijk maar van 1 CPU tegelijk gebruik maken. In deze situatie kan je naar mijn mening dan ook alleen de performance van deze applicatie verhogen door hoger geklokte cpu's te plaatsen met meer singethread performance of de applicatie multithreaded laten ontwikkelen.

[Equator]

squaddie schreef op vrijdag 06 september 2013 @ 14:39:
Het is onwaarschijnlijk dat het uitschakelen van hyper threading de performance verbeterd. Hyper treading is primair een techniek om de reken-eenheden van de processor beter te benutten. Overigens zijn er wel situaties waarin hyper treading negatieve invloed heeft op de performance, maar ik acht het onwaarschijnlijk dat dit van toepassing is op jouw host.

IMHO zorgt HTT ervoor dat een enkele core twee threads tegelijkertijd kan afhandelen. Dat heeft niet specifiek met rekenen te maken.

[Wim-Bart]

Meerdere cores heeft altijd zin, waarom, omdat een Windows, Linux of ieder ander modern OS Multi threaded is. Binnen een OS zijn er altijd meer dan 1 threads actief. Voordeel van meerdere cores is dat er meer werk per toegewezen share afgehandeld kan worden.

[CAPSLOCK2000]

Het nadeel van meerder cores is dat je het moeilijker maakt voor de scheduler van VMWare. In mijn omgeving hebben de meeste VMs helemaal geen twee cores nodig omdat ze toch 90% van de tijd niks doen en zelfs als ze wel actief zijn CPU maar zelden de bottleneck is.

[Wim-Bart]

CAPSLOCK2000 schreef op zaterdag 07 september 2013 @ 00:23:
Het nadeel van meerder cores is dat je het moeilijker maakt voor de scheduler van VMWare. In mijn omgeving hebben de meeste VMs helemaal geen twee cores nodig omdat ze toch 90% van de tijd niks doen en zelfs als ze wel actief zijn CPU maar zelden de bottleneck is.

Op een vrij rustig systeem maakt dat helemaal niets uit tenslotte dat de hypervisor meer werk moet verzetten. Wat ik zelf ervaar is dat met meerdere vCPU's je VM gewoon meer respronsive is. Maar inderdaad, in de meeste gevallen is het aan te raden om gewoon maar 1 vCPU toe te wijzen.

Overigens, wanneer je een 2008R2 VM hebt ingespoeld met meer dan 1 vCPU en je gaat terug naar 1 vCPU moet je niet vergeten om

code:

bcdedit /set detecthal yes

uit te voeren. En wanneer je van 1 vCPU naar meerdere cores eveneens. Zonder dat zal het allemaal performancewise geen zin hebben

O ja, juiste procedure is:

code:

Shutdown VM
vCPU wijzigen
VM booten
Commando: bcdedit /set detecthal yes
VM reboot

[ Voor 6% gewijzigd door Wim-Bart op 07-09-2013 13:03 ]

[squaddie]

Equator schreef op vrijdag 06 september 2013 @ 20:14:
[...]

IMHO zorgt HTT ervoor dat een enkele core twee threads tegelijkertijd kan afhandelen. Dat heeft niet specifiek met rekenen te maken.

offtopic:
Indien HTT daadwerkelijk twee threads kan afhandelen zou de prestatiewinst groter moet zijn dan 20 tot 30 procent die in de praktijk met hypertreading wordt behaald.

In een versimpelde weergave van een processor kan je deze zien als een pipeline (transportband) met aan het einde ervan de integer en floating point units (de daadwerkelijke verwerkingseenheden). In de ideale wereld staat bij elke kloktik een instructie klaar voor verwerking door een van de units. In de praktijk komt door diverse redenen voor dat transportband geen instructies klaar heeft staan en doen de units niets.

Met hypertreading wordt er een tweede transportband naast de eerste gelegd en in de ideale wereld staat er zowel een integer en floating point instructie te wachten voor verwerking en kan de processor op dat moment twee threats gelijktijdig verwerken. In de praktijk is dit lang niet altijd het geval, maar bied nog steeds de mogelijkheid om via twee transportbanden instructies aan te leveren en daarmee hogere kans om de verwerkingseenheden aan het werk te houden en zo de rekenkracht van de processor te verhogen.

[Equator]

offtopic:
Met alle respect, maar je zegt exact hetzelfde als ik. Een enkele core kan twee threads tegelijkertijd verwerken. Echter omdat bepaalde zaken toch nog door dezelfde core afgehandeld moet worden is de performance winst inderdaad maar 30%.