Hoi allemaal,

Voor een project ben ik met een test bezig om Windows 2008R2-SP1 Remote Desktop Server (RDS) virtueel aan te bieden op ESXi 4.1 Update 1.

De server waarop ik test kan ivm lokale diskruimte maximaal 4 Virtuele servers kwijt. Remote storage is in principe geen optie.

De fysieke server is een Dell R910 met 4 L7555 processoren a 8 cores met HT en 128 GB memory. In totaal dus 64 logische processoren.

Omdat ik in ESXi maar maximaal 8vCPU's kan toewijzen, bedacht ik dat het een goed idee is om HT uit te schakelen, zodat de 32 cores die dan beschikbaar zijn, netjes worden benut door de 4 VM's met ieder 8 vCPU's. Dit omdat de VM volgens mij nooit meer CPU resources gaat aanspreken dan de volledige belasting van de 8 vCPU's, ondanks dat de host wellicht nog resources beschikbaar heeft.

Is dit een logische gedachte? Of haal ik met HT enabled toch meer performance en zie ik iets over het hoofd? Ik weet dat de CPU scheduler van ESXi 4.1 prima met HT kan omgaan, maar ik heb het idee dat ik dan de helft van de cores niet ga benutten.

Groeten,
Rob

Het is altijd aan te raden HT aan te zetten

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

Dat zie je goed. Sowiezo is het voor RDS (of terminal server) beter om HT uit te zetten omdat je dan de volledige CPU cache kan aanspreken. Anders maar de helft per LCPU.

Ik weet alleen niet of 8 vCPU's per machine zo'n goed idee is. Je krijgt meer users op je hardware als je meer RDS servers uitrolt met minder CPU's. Dus ipv 4x8 naar 8x4 of zelfs 16x2. En als je dan toch bezig bent zou ik 1 core vrij laten als het ff kan. Dan weet je zeker dat het management gedeelte van vmware ook nog wat cpu "lucht" heeft zonder dat dit direct ready time op 8 cores veroorzaakt.

Nee dus....

Hm shit,

http://sudrsn.wordpress.com/2010/07/21/ ... e-vsphere/

_________________
| Blog.vmpros.nl | Twitter | DBL | vExpert 2010/2011/2012 |

Over het algemeen zie ik met CPU's waar genoeg cache in zit (E7 series) een aanzienlijke afname in cache latency met HT enabled in onze render omgeving. Verschil in taken van 4a5 uur loopt soms op naar 30% winst.
Ook lijkt het (gevoelsmatig) dat vm's met 2 vCPU's een stuk vlotter reageren wanneer deze op dezelfde host staan met 4 of 8 vCPU vm's.
Met name grafische applicaties op view met meer video geheugen hebben vrijwel geen last van lag meer.

Hoi,



Okee bedankt. Daar kan ik wat mee.



Dit lees ik vaker (minder vCPU's per VM - meer VM's). Dat begrijp ik niet zo goed. Zeker niet met 8 cores per pCPU (8vCPU's op 1 pCPU komt in gedachte).
Kort door de bocht geef je je VM een extra bak CPU resources en benut je toch juist je CPU resources beter, omdat je verhoudingsgewijs minder OS overhead hebt? RDS gaat die bak CPU resources bij hoge load zeker gebruiken (en nodig hebben).

Maar de werkelijke reden waarom ik 4 VM's x 8vCPU's configureer is omdat ik de VM's op lokale storage moet plaatsen en niet op remote storage. Hierdoor ben ik beperekt in de diskruimte en kan ik dus niet meer dan 4 VM's kwijt. Dit is een beperking waar ik rekening mee moet houden.



Ik zou eventueel een VM met 7 vCPU's kunnen configureren, maar dat voelt wel heel onnatuurlijk aan en maakt de 4e VM niet uniform. Ik ging er eigenlijk van uit dat de ESXi z'n eigen core processen een danige prio geeft dat het ten alle tijde voorrang heeft op datgeen wat de VM's aan CPU resources vragen.

Groeten,
Rob

Helaas is er ook nog software die niets snapt van een oneven (anders dan 1) aantal cpu's.

Op basis van de artikelen die ik gelezen heb is de architectuur van ESX(i) is de reden waarom de voorkeur uitgaat naar meerdere kleine VMs een of twee vCPUs ipv enkele grote VMs met meer dan twee vCPUs. De architectuur van ESX is dat alle vCPUs van een VM op het zelfde moment processortijd krijgen. Dit heeft te maken met het verleden toen het besturingssysteem direct op de hardware geinstalleerd werd had het besturingssysteem altijd toegang tot alle CPUs. Het kan dus zijn dat er besturingssystemen zijn waarvan de scheduler het niet leuk vindt als deze geen permanente toegang heeft tot alle CPUs. VMware heeft dit opgelost door alle vCPUs ongeacht of ze het wel of niet nodig hebben tegelijkertijd processortijd te geven.

Hieruit volgt dat het voor de scheduler veel lastiger is om processortijd te geven aan een 8 vCPU VM dan aan een 1 vCPU VM omdat het pas die processortijd kan geven als de benodigde aantal pCPUs vrij zijn. De enige mogelijkheden die de scheduler heeft is de 8 vCPU VM laten wachten of de overige VMs laten wachten en beide zie je terug als een oplopende CPU ready.

klopt wat squaddie zegt. Maar het ligt wel iets genuanceerder tegenwoordig. Ten eerste heeft VMware iets ingevoerd dat ze relaxed co-scheduling noemen. Het is dus niet meer zo dat als 1 cpu in een smp vm gescheduled wordt ze direct allemaal gescheduled moeten zijn. dit levert dus meer vrijheid op voor de scheduler maar nog niet zoveel als dat je alleen maar 1x vCPU VMs zou hebben.

Verder is het co-schedulen veel minder een probleem als je niet overcommit. Vandaar mijn suggestie om een cpu leeg te laten. Nu overcommit je welliswaar niet de VM resources maar vergeet niet dat ESX zelf ook wel wat cpu tijd wil hebben. Door een core vrij te houden voorkom je alle kan op contention en heb je dus geen last van het co-schedule principe.

Wat een veel belangrijker reden is om voor minder vCPU's te kiezen is dat de windows scheduler steeds inefficienter wordt naarmate er meer cpu's zijn. heb ooit eens gelezen dat als je windows iets van 16 cpu's geeft er onder grote load een hele cpu aan scheduling verloren gaat. windows werkt dus efficienter als je minder CPU's hebt. Hoe het nu met Win2008 zit weet ik niet. Ik ga er vanuit dat die weer wat efficienter is geworden.

Klopt, dat staat in de boeken van Grimm en Andersen.

Als er iets effficient is (en dan laat ik NT4 er wel even erbuiten) in resource scheduling dan is dat de windows kernel, al helemaal wanneer er de inferieure HT van de Pentium4/Xeon2 series gebruikt wordt.

Bedankt voor jullie reacties!

Naar aanleiding van jullie reacties overweeg ik nu te kiezen om iets te knijpen in de diskconfiguratie en thin provisioning toepassen op disken waar de profiles en applicaties komen te staan en dan kiezen voor 5 VM's met ieder 6 cores. Dan houd ik 2 fysieke cores "over" voor ESXi management.

Wat denken jullie daarvan?

Misschien moet ik beide scenario's maar eens testen om te kijken wat het qua performance en resource verbruik doet.

Groeten,
Rob

Hoeveel vCPU's heb je nodig ? Het heeft natuurlijk geen zin er 6 toe te wijzen terwijl je aan 2 al genoeg hebt.

Ik denk dat je beter kunt stellen hoeveel pCPU cores ik aan het werk wil zetten. Mijn ervaring met RDS is dat je nooit teveel CPU resources kunt hebben.

Ik heb 32 fysieke cores en zet er in het 2e scenario 30 vCPU's op een host in (5 VM's met ieder 6 vCPU's).

RDS = ?