Vreemde performance icm Hyper-V

[ndonkersloot]

Beste Tweakers,

Ik heb een zeer vreemd probleem betreffende perfomance in de VM's op mijn Hyper-V host.
Er staan uiteraard meerdere VM's op de Hyper-V host, waaronder een database server en een terminal server.
De database server bevat zoals gezegd de database voor een applicatie en de terminal server een client voor die applicatie.

Een specifieke handeling binnen de applicatie op de terminal server duurt enkele minuten, stop ik alle VM's op deze Hyper-V host duurt die taak ~25 seconde.
Tot zover logisch, deze twee servers hoeven de beschikbare capaciteit niet meer te delen met andere VM's.

Als er in totaal 8 VM's gestart zijn, blijft deze taak binnen ~25 seconde afgerond te zijn.
Start ik een 9de VM komt er 10 seconde bij de verwerking, nog een VM gestart, weer 10 seconde etc. etc.
Ergens lijkt er dus een bottleneck te zijn, al zie ik die niet terug in performance monitor. De CPU, MEM en DISK belasting zijn miniem.
Om uit te sluiten waar de bottleneck zich precies in voordoet ben ik op zowel CPU, memory, disk als network verschillende testen gaan uitvoeren.
Inmiddels teveel om allemaal te benomen, maar dit geeft een idee:

Als ik 8 VM's start en één daarvan 32 CPU's geef en 300GB RAM blijft de taak binnen 25 seconde afgerond te worden.
Start ik de 9de VM met maar 1 vCPU, limiteer ik de CPU en memory naar het minimum is de taak weer precies 10 seconde trager.
Verplaats ik die 9de VM tevens naar een andere disk set (SSD insteek module) die dus los staat van de RAID controller en harddisks die gebruikt wordt voor de overige 8 VM's gaat het alsnog langzaam.

Het maakt niet uit of de 8 VM's gebruikt of ongebruikt worden, dit geeft geen verschil op performance.
Dit is natuurlijk een uiterst vreemd verhaal maar iemand die ook ervaringen heeft met performance degradatie als er meerdere zelfs onbelaste VM's starten?

Wat informatie over de setup:

2x CPU: Intel Xeon E5-2699v3
RAM: 768GB
Hyper-V Host is Windows Server 2016
DB en TS is Windows Server 2012

[Gomez12]

Gaat het ook bij de 10e, 11e etc steeds trager of blijft die 10sec redelijk stabiel tot je de 16 raakt?

Want 8 vind ik zo'n dubieus "half-binair" getal dat ik me best kan voorstellen dat ze op machten van 2 hun cpu-slicing anders gaan toepassen waardoor je bij 1-8 op manier 1 werkt en bij 9-16 op manier 2. En bij 17-32 op manier 3.

En dat manier 2 dan 10 sec langzamer is, tja dat is dan maar zo je host moet ook meer verdelen dus ergens moet het tijd kosten.

[ndonkersloot]

Gomez12 schreef op vrijdag 26 januari 2018 @ 16:32:
Gaat het ook bij de 10e, 11e etc steeds trager of blijft die 10sec redelijk stabiel tot je de 16 raakt?

Want 8 vind ik zo'n dubieus "half-binair" getal dat ik me best kan voorstellen dat ze op machten van 2 hun cpu-slicing anders gaan toepassen waardoor je bij 1-8 op manier 1 werkt en bij 9-16 op manier 2. En bij 17-32 op manier 3.

En dat manier 2 dan 10 sec langzamer is, tja dat is dan maar zo je host moet ook meer verdelen dus ergens moet het tijd kosten.

Het lijkt echt bij iedere VM die gestart wordt 10 seconde langzamer gaan. Op deze host staan 101VM's dus als die allemaal gestart zijn, al is het zelfs onbelast en via de Hyper-V manager beperkt in capaciteit, duurt die handeling spontaan minuten..

[downtime]

Je hebt in totaal 36 fysieke cores. Hoeveel CPU's ken je aan elke VM toe? Ik kan me voorstellen dat performance afneemt als het aantal aan VM's toegewezen CPU's groter wordt dan het aantal fysiek beschikbare cores.

[Vorkie]

Heb je hier al eens naar gekeken?

https://blog.workinghardi...rocessor-relative-weight/

[ndonkersloot]

@downtime
@Vorkie

Aller eerst bedankt voor jullie input!

Yup, allebei bekend, in totaal 18 vCPU's toegekend aan de VM's nog genoeg over dus .
Zelfs als de relative weight en limit op 1% wordt gezet voor de 9de VM is het 10 seconde trager..

[Gomez12]

Zet die specifieke handeling eens om naar een specifieke query en draai die dan eens uit ssms dan kan ssms je tenminste vertellen of het in je db of in je client gedeelte zit.

[MAX3400]

NUMA? Je hebt 2 sockets maar Hyper-V laat standaard toe dat de fysieke sockets "verdeeld" worden over alle vCPU's.

Zomaar kans dat als je je VMs verdeelt over de 2 sockets, dat het beter gaat. Hou ook in de gaten hoe je memory-controllers het aanwezige RAM per socket alloceren; ook hier is je NUMA boundary van belang.

[ndonkersloot]

@Gomez12
Het is helaas geen SQL maar een assurantie pakket. Binnen dat pakket wordt een bepaalde actie uitgevoerd. Als ik die actie op de TS of DB server uitvoer geeft dat geen verschil.

@MAX3400
Bedankt voor je tip!
NUMA wordt momenteel niet gebruikt, ga hier zeker mee experimenteren!

[_Arthur]

Tiwazz schreef op zaterdag 27 januari 2018 @ 00:32:
Yup, allebei bekend, in totaal 18 vCPU's toegekend aan de VM's nog genoeg over dus .

Je zei net 8 VM's met 1 daarvan 32 vCPU's, dat maakt totaal 39 vCPU's toegewezen, minimaal.

Som eens op hoe de VM config er uitziet;
VM1: 2 vCPU's, 32GB ram
VM2: 1 vCPU, 16GB ram
...etc (als voorbeeld)