VMWare 5i: Cores, vCPU's en HT

[CORVETTE]

Hoe meer ik lees over ESX en vCPU's en Hyper Treading, hoe meer tegenstrijdigheden ik tegenkom.

Hoe zit het nou met:

1:
Wanneer je een vCPU toewijzt aan VM host, wordt dan 1 CPU core alleen aangesproken ?
Is dus een vCPU 1 op 1 een physieke core ?

2:
Bij mijn weten is Hyper Treading een foefje om van 1 core, gedeeltelijk een 2e core erbij laten krijgen.
Volgens mijn ( oude ) ideeen, zijn 2 echte cores beter.
Klopt dat ?

3:
Zie 2.
Klopt het dan ook dat ik beter een server met zoveel mogelijk echte core's kan nemen, ipv Hyper Treading te gebruiken ? Dat vraag ik omdat we standaard altijd HP's DL380's kopen ( Intel ), maar de 385 ( AMD ) heeft veel meer core's. Qua performance per core wel wat minder maar .....

[Microkid]

1. Nee. Een vCpu wordt aan elke willekeurige fysieke core toegewezen die op dat moment vrij is. Dat doet de scheduler. Je vm draait dus feitelijk elke nanoseconde steeds op een andere core. (Tenzij je kiest voor cou affinity en een vcpu hard aan een fysieke core toekend. Maar dat moet je eigenlijk nooit doen want daarmee verstoor je de scheduler en de flexibiliteit om cpu cycles over cores te verdelen.)
2. Ja, HT geeft zo'n 20% verbetering. Een echte core natturlijk veel meer. Maar ... Voor thuis gebruik is een quad core met HT prima hoor
3. Hangt ook van je workload af. Als al je cores altijd vol benut worden kan het geen kwaad om extra fysieke cores te nemen. Maar meestal is je memory eerder uitgeput dan je cpu.

[ Voor 22% gewijzigd door Microkid op 22-07-2013 20:47 ]

[spone]

1. Ja en nee. Een vCPU draait niet altijd op dezelfde fysieke core, maar nooit meer dan op 1 core tegelijk. Met andere woorden: als je core 3GHz is, en je wijst de VM 4GHz toe terwijl deze maar 1 vCPU heeft zal deze nooit meer dan die 3GHz kunnen gebruiken.

2&3: met ^

[ Voor 3% gewijzigd door spone op 22-07-2013 20:46 ]

[p.m.]

Idealiter wil je voor een virtualisatie-host een CPU hebben met veel cores en hyperthreading, i.m.o. En als je een keuze moet maken tussen die 2, dan ga je voor cores.
Op hosts met 2 Ghz Intel-cpu's met 10 cores en ht (40 logische processors) hebben we 100+ VM's gedraaid.

[CORVETTE]

Ok. Dus grofweg kun je zeggen: CPU + HT is ongeveer: 1,2 CPU.

Zijn er ergens performance grafieken te vinden, waarin bijvoorbeeld een 16 core AMD wordt vergeleken met een Intel 10 of 12 core ?

[KillerAce_NL]

Al vind je er 1, heb je niet veel aan. De workload is voor elke omgeving anders, dit omdat je waarschijnlijk ook diverse servertypes (vm's) mixt in je evt cluster.

[Ethirty]

Maar wat voor tegenstrijdigheden kom je dan tegen?

Cores zijn beter dan HT, maar de ratio cores/vCPU bepaalt of je baat heb bij veel meer cores. In bepaalde workloads kan je misschien wel 1:10 of zelfs 1:20 halen. Dan kan je wel 16 cores hebben, maar die staan dan nog niks te doen. In ons cluster zie ik volgens mij zelden een belasting boven de 50% CPU, dus cores zat (12 per host, gemiddeld denk ik zo'n 15-18 vCPU)

Trouwens ook nooit teveel vCPU's toekennen aan een VM. Dit geeft in bepaalde situaties alleen maar extra vertraging omdat alle fysieke cores beschikbaar moeten zijn (CPU-ready time meen ik).

[tomtom901]

Die vertraging is inderdaad CPU ready time en geeft aan de tijd waarbij een vCPU klaar is voor een opdracht maar nog gescheduled moet worden op de pCPU.

[KoeKk]

Ethirty schreef op dinsdag 23 juli 2013 @ 12:11:
Trouwens ook nooit teveel vCPU's toekennen aan een VM. Dit geeft in bepaalde situaties alleen maar extra vertraging omdat alle fysieke cores beschikbaar moeten zijn (CPU-ready time meen ik).

Sterker nog, dit geeft niet in bepaalde situaties extra vertraging, maar in bijna alle situaties geeft het vertraging. Alleen als je workload (sterk) multithreaded is, en continue een hoge CPU load genereerd, heeft het nut om er een extra vCPU bij te plaatsen

[Ethirty]

Ik kan melden dat bijv Exchange of een RDS server met een paar users toch graag meer dan 1 vCPU willen. Maar je moet er dan niet gelijk 4 in willen zetten, dan slaat het voordeel weer om in een nadeel. Met 2 of 3 werkt het vaak prima. Een DC, file server of lichte DB server is het inderdaad onzin.

[chaoscontrol]

RDS tot 10 gebruikers met zon 3 apps per user kan makkelijk op 1 vCPU in mijn ervaring. Zelfs dan komt de load van die ene vCPU niet boven de 33% (afgelopen 2 weken).

[Ethirty]

Dat hebben wij nog niet voor elkaar gekregen. Maar elke klant heeft op zijn minst één idiote applicatie die CPU slurpt en niks doet

[CORVETTE]

Ik persoonlijk moet zeggen dat ik altijd 2 vCPU's toe ken. Maar dat is puur omdat ik zelf Windows niet vooruit te branden vind als ik de servers beheer. Met 1 vCPU heb ik het idee dat de boel allemaal wat trager gaat in de gui van Windows.

[KoeKk]

CORVETTE schreef op woensdag 24 juli 2013 @ 09:12:
Ik persoonlijk moet zeggen dat ik altijd 2 vCPU's toe ken. Maar dat is puur omdat ik zelf Windows niet vooruit te branden vind als ik de servers beheer. Met 1 vCPU heb ik het idee dat de boel allemaal wat trager gaat in de gui van Windows.

Dan kan het haast niet anders dan dat het aantal vCPU's lager of gelijk ligt aan het aantal cores in je fysieke server. Anders moet je tegen CPU ready time issues aanlopen. Sowieso zou ik dit ZSM terugdraaien, aangezien echte elke VMware nerd zegt dat je dit absoluut niet moet doen. Alleen resources toekennen die ook gebruikt worden.

[Jazzy]

CORVETTE schreef op woensdag 24 juli 2013 @ 09:12:
Ik persoonlijk moet zeggen dat ik altijd 2 vCPU's toe ken. Maar dat is puur omdat ik zelf Windows niet vooruit te branden vind als ik de servers beheer. Met 1 vCPU heb ik het idee dat de boel allemaal wat trager gaat in de gui van Windows.

Dan heb je een andere performance bottleneck. Best practice is om alleen uit te delen wat je echt nodig hebt, dus starten met 1 vCPU en alleen indien nodig toevoegen. Dit geldt net name voor VMWare maar ook voor Hyper-V.

[KillerAce_NL]

En zeker geen 2e cpu toekennen omdat je zelf je desktop van de server te langzaam vind, dat is géén goede reden imho.
Een 2e core zal altijd resources pakken, als dat niet nodig is omdat de 1e core ook zo goed als nooit 100% draait, dan ben je resources aan het weggooien en schaad je mogelijk de performance van andere vm's.