7
Vmware ESX CPU Zuteilung Fragen
Hi, ich hab da mal eine Verständnisfrage
Eine unter meinen vielen Aufgaben besteht akturell darin, seltsame Performanceschwankungen unter ESXI 6.7 zu untersuchen.
Der Kunde beklagte daß eine bestimmte Software sporadisch hängt bzw dramatische Laufzeitzuwächse hat.
Dort gibts eine Terminalserverfarm, 13 Hosts auf denen tlw 7-10 User parallel drauf sind.
Ich hab dann mal den Kundenworkflow automatisiert (mit einem Autohotkey Skript im Loginskript der User) und eine zentrale Datenablage gebastelt.
Der Host dazu läuft auf einem Single CPU System, der SQL Server ist eine VM auf einem separatem Systsem mit NVME Speicher und einer Infiniband-Anbindung an den Terminalserver, die Clients gehen über eine 1 GBit Schnittstelle an die Terminalserver.
Die Applikation hat eine WPF Oberfläche, ist ansonsten streng singlethreaded und nutzht c++2015 und ist 32 bittig.
Die VMs dafür haben 8 vCPUs zugewiesen gekriegt... und gemäß einem VMware Whitepaper 1 Core/Socket.
Aber bei VMware sind die Aussagen etwas vage, wie damit umgegangen wird aber was sie garantieren ist daß bei Zuweisung eines Cores auch maximal 100% (oder man reserviert gleich 100%) an Core-Rechenzeit geliefert wird. Der Host hat einen Xeon 2667v2, das sind 8 Cores mit 3,3 GHz, 16 threads. Am Host sehe ich dann auch 8x 3,3 GHz und die Last wird auf Core-Last gerechnet... wenn ich also 8 Instanzen meines Tests laufen hab geht die Lastanzeige am Host auf 100%. Was ja so auch richtig ist. Nur sind die Laufzeiten dann alles andere als linear.
Eine einzelne Instanz des Tests (95% CPU Zeit, 5% SQL Server Lesen und Schreiben) ist in 150 Sekunden zuende, lasse ich zwei parallel laufen verlängert sich die Laufzeit schon auf 180-200 Sekunden bei beiden Instanzen, vier Instanzen haben schon 240-300 Sekunden Laufzeit. Der Host zeigt 50% Last.
Und das war nur eine von vielen VMs, die anderen haben noch garnichts gemacht.
Die Informationslage ist nicht gerade klar
- VMware schreibt, daß die CPU-Last nach Cores verteilt wird. Aber offenbar nicht linear.
- VMware schreibt, daß die jeweils inaktiven Thrads "idle" geschaltet werden... wenn ich aber meine ESX Lastauswerung anschaue sehe ich bei 8 Instanzen meines Tests über 2 VMs verteilt Last auf jedem einzelnen Thread, ich hab in dem Performancegraph 17 Einträge.
- Vmware schreibt, daß 1 core per socket optimal ist, aber ich hab schon ein Gegenbeispiel mit dem MS SQL Server in einer 10 Core-Konfiguration. 10 Cores in einem Socket ist da 20% schneller wie 1 Core in 10 Sockets.
Ist VMware da etwa kaputt? Oder ist die mangelnde Parallelisierbarkeit von dot net Anwendungen ein bekanntes Problem?
Eine unter meinen vielen Aufgaben besteht akturell darin, seltsame Performanceschwankungen unter ESXI 6.7 zu untersuchen.
Der Kunde beklagte daß eine bestimmte Software sporadisch hängt bzw dramatische Laufzeitzuwächse hat.
Dort gibts eine Terminalserverfarm, 13 Hosts auf denen tlw 7-10 User parallel drauf sind.
Ich hab dann mal den Kundenworkflow automatisiert (mit einem Autohotkey Skript im Loginskript der User) und eine zentrale Datenablage gebastelt.
Der Host dazu läuft auf einem Single CPU System, der SQL Server ist eine VM auf einem separatem Systsem mit NVME Speicher und einer Infiniband-Anbindung an den Terminalserver, die Clients gehen über eine 1 GBit Schnittstelle an die Terminalserver.
Die Applikation hat eine WPF Oberfläche, ist ansonsten streng singlethreaded und nutzht c++2015 und ist 32 bittig.
Die VMs dafür haben 8 vCPUs zugewiesen gekriegt... und gemäß einem VMware Whitepaper 1 Core/Socket.
Aber bei VMware sind die Aussagen etwas vage, wie damit umgegangen wird aber was sie garantieren ist daß bei Zuweisung eines Cores auch maximal 100% (oder man reserviert gleich 100%) an Core-Rechenzeit geliefert wird. Der Host hat einen Xeon 2667v2, das sind 8 Cores mit 3,3 GHz, 16 threads. Am Host sehe ich dann auch 8x 3,3 GHz und die Last wird auf Core-Last gerechnet... wenn ich also 8 Instanzen meines Tests laufen hab geht die Lastanzeige am Host auf 100%. Was ja so auch richtig ist. Nur sind die Laufzeiten dann alles andere als linear.
Eine einzelne Instanz des Tests (95% CPU Zeit, 5% SQL Server Lesen und Schreiben) ist in 150 Sekunden zuende, lasse ich zwei parallel laufen verlängert sich die Laufzeit schon auf 180-200 Sekunden bei beiden Instanzen, vier Instanzen haben schon 240-300 Sekunden Laufzeit. Der Host zeigt 50% Last.
Und das war nur eine von vielen VMs, die anderen haben noch garnichts gemacht.
Die Informationslage ist nicht gerade klar
- VMware schreibt, daß die CPU-Last nach Cores verteilt wird. Aber offenbar nicht linear.
- VMware schreibt, daß die jeweils inaktiven Thrads "idle" geschaltet werden... wenn ich aber meine ESX Lastauswerung anschaue sehe ich bei 8 Instanzen meines Tests über 2 VMs verteilt Last auf jedem einzelnen Thread, ich hab in dem Performancegraph 17 Einträge.
- Vmware schreibt, daß 1 core per socket optimal ist, aber ich hab schon ein Gegenbeispiel mit dem MS SQL Server in einer 10 Core-Konfiguration. 10 Cores in einem Socket ist da 20% schneller wie 1 Core in 10 Sockets.
Ist VMware da etwa kaputt? Oder ist die mangelnde Parallelisierbarkeit von dot net Anwendungen ein bekanntes Problem?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 857076801
Url: https://administrator.de/contentid/857076801
Ausgedruckt am: 23.11.2024 um 22:11 Uhr
7 Kommentare
Neuester Kommentar
Moin..
gern..
Eine unter meinen vielen Aufgaben besteht akturell darin, seltsame Performanceschwankungen unter ESXI 6.7 zu untersuchen.
Der Kunde beklagte daß eine bestimmte Software sporadisch hängt bzw dramatische Laufzeitzuwächse hat.
was ist das für eine Software genau?
Ich hab dann mal den Kundenworkflow automatisiert (mit einem Autohotkey Skript im Loginskript der User) und eine zentrale Datenablage gebastelt.
was das system aber nicht schneller macht... 
lass mich raten, der Server dazu ist ein HP DL380 G8, oder ein Dell R710.
Die Applikation hat eine WPF Oberfläche, ist ansonsten streng singlethreaded und nutzht c++2015 und ist 32 bittig.
noch mal, was ist das für eine Software?
Die VMs dafür haben 8 vCPUs zugewiesen gekriegt... und gemäß einem VMware Whitepaper 1 Core/Socket.
äh.. sagtest du nicht, du hast eine 2667v2 CPU, mit 8 Cores mit 3,3 GHz!
wenn überhaubt, würde ich je nach VM 2 vCPUs anfangen!
Aber bei VMware sind die Aussagen etwas vage, wie damit umgegangen wird aber was sie garantieren ist daß bei Zuweisung eines Cores auch maximal 100% (oder man reserviert gleich 100%) an Core-Rechenzeit geliefert wird. Der Host hat einen Xeon 2667v2, das sind 8 Cores mit 3,3 GHz, 16 threads. Am Host sehe ich dann auch 8x 3,3 GHz und die Last wird auf Core-Last gerechnet... wenn ich also 8 Instanzen meines Tests laufen hab geht die Lastanzeige am Host auf 100%. Was ja so auch richtig ist. Nur sind die Laufzeiten dann alles andere als linear.
ja... biite nicht Vergessen, dein host braucht auch CPU zeit und RAM.
was ich bis jetzt lese ist, dein System ist offnungslos überbucht.. die VMware sind die Aussagen können nur vage sein- es ist schon ein unterschied, ob wir von einer alten Xeon 2667v2 CPU reden, oder von einer Intel Xeon Gold.
Eine einzelne Instanz des Tests (95% CPU Zeit, 5% SQL Server Lesen und Schreiben) ist in 150 Sekunden zuende, lasse ich zwei parallel laufen verlängert sich die Laufzeit schon auf 180-200 Sekunden bei beiden Instanzen, vier Instanzen haben schon 240-300 Sekunden Laufzeit. Der Host zeigt 50% Last.
Und das war nur eine von vielen VMs, die anderen haben noch garnichts gemacht.
Die Informationslage ist nicht gerade klar
- VMware schreibt, daß die CPU-Last nach Cores verteilt wird. Aber offenbar nicht linear.
- VMware schreibt, daß die jeweils inaktiven Thrads "idle" geschaltet werden... wenn ich aber meine ESX Lastauswerung anschaue sehe ich bei 8 Instanzen meines Tests über 2 VMs verteilt Last auf jedem einzelnen Thread, ich hab in dem Performancegraph 17 Einträge.
- Vmware schreibt, daß 1 core per socket optimal ist, aber ich hab schon ein Gegenbeispiel mit dem MS SQL Server in einer 10 Core-Konfiguration. 10 Cores in einem Socket ist da 20% schneller wie 1 Core in 10 Sockets.
das kannst du pauschal so nicht sagen....
Ist VMware da etwa kaputt? Oder ist die mangelnde Parallelisierbarkeit von dot net Anwendungen ein bekanntes Problem?
nee, kaputt ist da nix, aber zu 100% überbucht. das system ist schlicht überlastet.
da hilft nur aufrüsten
Frank
gern..
Eine unter meinen vielen Aufgaben besteht akturell darin, seltsame Performanceschwankungen unter ESXI 6.7 zu untersuchen.
Der Kunde beklagte daß eine bestimmte Software sporadisch hängt bzw dramatische Laufzeitzuwächse hat.
Dort gibts eine Terminalserverfarm, 13 Hosts auf denen tlw 7-10 User parallel drauf sind.
ok.... alles Server 2019... oder Server 2016?Ich hab dann mal den Kundenworkflow automatisiert (mit einem Autohotkey Skript im Loginskript der User) und eine zentrale Datenablage gebastelt.
Der Host dazu läuft auf einem Single CPU System, der SQL Server ist eine VM auf einem separatem Systsem mit NVME Speicher und einer Infiniband-Anbindung an den Terminalserver, die Clients gehen über eine 1 GBit Schnittstelle an die Terminalserver.
ok, also 2 Bleche, 1 Host für SQL, und ein Host für 13 VMs unter ESXI 6.7. mit einer intel Xeon 2667v2 CPU.lass mich raten, der Server dazu ist ein HP DL380 G8, oder ein Dell R710.
Die Applikation hat eine WPF Oberfläche, ist ansonsten streng singlethreaded und nutzht c++2015 und ist 32 bittig.
Die VMs dafür haben 8 vCPUs zugewiesen gekriegt... und gemäß einem VMware Whitepaper 1 Core/Socket.
wenn überhaubt, würde ich je nach VM 2 vCPUs anfangen!
Aber bei VMware sind die Aussagen etwas vage, wie damit umgegangen wird aber was sie garantieren ist daß bei Zuweisung eines Cores auch maximal 100% (oder man reserviert gleich 100%) an Core-Rechenzeit geliefert wird. Der Host hat einen Xeon 2667v2, das sind 8 Cores mit 3,3 GHz, 16 threads. Am Host sehe ich dann auch 8x 3,3 GHz und die Last wird auf Core-Last gerechnet... wenn ich also 8 Instanzen meines Tests laufen hab geht die Lastanzeige am Host auf 100%. Was ja so auch richtig ist. Nur sind die Laufzeiten dann alles andere als linear.
was ich bis jetzt lese ist, dein System ist offnungslos überbucht.. die VMware sind die Aussagen können nur vage sein- es ist schon ein unterschied, ob wir von einer alten Xeon 2667v2 CPU reden, oder von einer Intel Xeon Gold.
Eine einzelne Instanz des Tests (95% CPU Zeit, 5% SQL Server Lesen und Schreiben) ist in 150 Sekunden zuende, lasse ich zwei parallel laufen verlängert sich die Laufzeit schon auf 180-200 Sekunden bei beiden Instanzen, vier Instanzen haben schon 240-300 Sekunden Laufzeit. Der Host zeigt 50% Last.
Und das war nur eine von vielen VMs, die anderen haben noch garnichts gemacht.
Die Informationslage ist nicht gerade klar
- VMware schreibt, daß die CPU-Last nach Cores verteilt wird. Aber offenbar nicht linear.
- VMware schreibt, daß die jeweils inaktiven Thrads "idle" geschaltet werden... wenn ich aber meine ESX Lastauswerung anschaue sehe ich bei 8 Instanzen meines Tests über 2 VMs verteilt Last auf jedem einzelnen Thread, ich hab in dem Performancegraph 17 Einträge.
- Vmware schreibt, daß 1 core per socket optimal ist, aber ich hab schon ein Gegenbeispiel mit dem MS SQL Server in einer 10 Core-Konfiguration. 10 Cores in einem Socket ist da 20% schneller wie 1 Core in 10 Sockets.
Ist VMware da etwa kaputt? Oder ist die mangelnde Parallelisierbarkeit von dot net Anwendungen ein bekanntes Problem?
da hilft nur aufrüsten
Frank
Zitat von @GrueneSosseMitSpeck:
- Vmware schreibt, daß 1 core per socket optimal ist, aber ich hab schon ein Gegenbeispiel mit dem MS SQL Server in einer 10 Core-Konfiguration. 10 Cores in einem Socket ist da 20% schneller wie 1 Core in 10 Sockets.
- Vmware schreibt, daß 1 core per socket optimal ist, aber ich hab schon ein Gegenbeispiel mit dem MS SQL Server in einer 10 Core-Konfiguration. 10 Cores in einem Socket ist da 20% schneller wie 1 Core in 10 Sockets.
Wo schreibt Vmware das? Ich hatte Anfangs auch so eine Konfiguration übernommen. Dann aber mal eingelesen und bin schließlich auch bei N Cores auf 1 Socket gelandet. Einen spürbaren Performance Schub von 20% gab es bei meinem SQL Server aber nicht.
Ansonsten schließe ich mich Frank an.
Zitat von @GrueneSosseMitSpeck:
Der Host dazu läuft auf einem Single CPU System, der SQL Server ist eine VM auf einem separatem Systsem mit NVME Speicher und einer Infiniband-Anbindung an den Terminalserver, die Clients gehen über eine 1 GBit Schnittstelle an die Terminalserver.
Der Host dazu läuft auf einem Single CPU System, der SQL Server ist eine VM auf einem separatem Systsem mit NVME Speicher und einer Infiniband-Anbindung an den Terminalserver, die Clients gehen über eine 1 GBit Schnittstelle an die Terminalserver.
Moin,
kannst du die Hardware- und VM Konfiguration noch mal detailieren? Die Anbindung der Clients ist bei Terminalserver ja relativ egal.
/Thomas
Zitat von @GrueneSosseMitSpeck:
Der Host hat einen Xeon 2667v2, das sind 8 Cores mit 3,3 GHz, 16 threads. Am Host sehe ich dann auch 8x 3,3 GHz und die Last wird auf Core-Last gerechnet... wenn ich also 8 Instanzen meines Tests laufen hab geht die Lastanzeige am Host auf 100%. Was ja so auch richtig ist. Nur sind die Laufzeiten dann alles andere als linear.
Also wenn ich das richtig deute dann hast du 8 pCores, 16 htCores. Ist Hyperthreading wirklich an oder eventuell deaktiviert?Der Host hat einen Xeon 2667v2, das sind 8 Cores mit 3,3 GHz, 16 threads. Am Host sehe ich dann auch 8x 3,3 GHz und die Last wird auf Core-Last gerechnet... wenn ich also 8 Instanzen meines Tests laufen hab geht die Lastanzeige am Host auf 100%. Was ja so auch richtig ist. Nur sind die Laufzeiten dann alles andere als linear.
Da drauf laufen dann 8 VMs a 1 vCore und nichts weiteres? (natürlich + dem Host, der braucht auch ab und zu CPU)
Für mich klingt das auch erstmal nach einem Problem durch Überbuchung wobei man hier verschiedene Fehler begehen kann. Ich bin mir aber noch nicht ganz sicher was das Problem ist, bitte nutze esxtop um die CPU Zeiten zu betrachten, guck dir das hier schon mal an https://www.heroix.com/blog/vmware-vcpu-over-allocation/ .
Hyperthreading ist aktiv... die Software heißt Comos falls die jemand kennt.
Arbeitet meist mit Mikrotransaktionen am SQL SErver, aber hin und wieder gibts auch ein mächtiges SQL Statement. Die 20% Performanceunterschied hatten wir bei einem hochgradig komplexen SQL Statement mit ca. 5000 Buchstaben Text drin das einen Din A 0 großen Ausführungsplan hat und reproduzierbar in 90 Sekunden fertig war mit 2 Sockets zu 5 Cores (am Host war HT ausgeschaltet) , 90 Sekunden mit 1 Socket zu 10 Cores, und fast 110 Sekunden mit 10 Sockets zu 1 Core.
Der Kunde mit den gefühlten Performanceproblemen war aber ein anderer, hat 6 oder 8 Virtualisierungshosts, Server 2016 als OS, Xeon v4 Gold mit 3 GHz, und SQL 2019 auf einem physischen Server der auf einem NVME Storage voller Optane SLC Module arbeitete, mit einem Backbonde mit 100 GBit.
Meine Testumgebung sind zwei isolierte Serverchen, Hyperthreading überall aktiv, der SQL server 2019 wie beim Kunden, der NVME
Hyperthreading ist aktiv
https://kb.vmware.com/s/article/1010184
Wer Lust hat kann man das Best practice durchlesen... ist quasi dasselbe für ESXI 6.7 und höher und hat auch Fallunterschiedungen, meist mit ESX 6.5 / niedriger und ESX 6.7 und höher.
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpa ...
Auf Seite 26 schreiben sie ein vCore = 1 physikalischer Thread, bitte immer 1x2 bis nx2 konfigurieren... in einigen VMwarew Blogs stehts anders - 1 vCore wird auf die Rechenleistung eines pCores gemappt.
Das benche ich uach noch aus... mit 4 Sessions meiner Software, die 100% auf einem Core bringt hab ich halt nur vier der virtuellen Cores ausgelastet und ca. 50% der CPU-Kapazitäten lt VMware Monitoring. Und das zählt Corecount X Takt (nicht Threads)
bin aber etwas weiter - ich hab den Benchmark in Einzelschritte aufgegliedert, und nur einer hatte Laufzeiten, die sich mit Anzahl der parallelen Sessions erhöht hatte, bei 4 Sessions kam ich auf einen Faktor 2. Alle anderen Schritte hatten fast exakt dieselben Laufzeiten, solange der Host nicht überlastet war. Nur mit 3 VMs und jeweils 5 Sessions war das Ding total am Ende, und da wurde die Rechenzeit auch nicht mehr fair verteilt.
Arbeitet meist mit Mikrotransaktionen am SQL SErver, aber hin und wieder gibts auch ein mächtiges SQL Statement. Die 20% Performanceunterschied hatten wir bei einem hochgradig komplexen SQL Statement mit ca. 5000 Buchstaben Text drin das einen Din A 0 großen Ausführungsplan hat und reproduzierbar in 90 Sekunden fertig war mit 2 Sockets zu 5 Cores (am Host war HT ausgeschaltet) , 90 Sekunden mit 1 Socket zu 10 Cores, und fast 110 Sekunden mit 10 Sockets zu 1 Core.
Der Kunde mit den gefühlten Performanceproblemen war aber ein anderer, hat 6 oder 8 Virtualisierungshosts, Server 2016 als OS, Xeon v4 Gold mit 3 GHz, und SQL 2019 auf einem physischen Server der auf einem NVME Storage voller Optane SLC Module arbeitete, mit einem Backbonde mit 100 GBit.
Meine Testumgebung sind zwei isolierte Serverchen, Hyperthreading überall aktiv, der SQL server 2019 wie beim Kunden, der NVME
Hyperthreading ist aktiv
https://kb.vmware.com/s/article/1010184
Wer Lust hat kann man das Best practice durchlesen... ist quasi dasselbe für ESXI 6.7 und höher und hat auch Fallunterschiedungen, meist mit ESX 6.5 / niedriger und ESX 6.7 und höher.
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpa ...
Auf Seite 26 schreiben sie ein vCore = 1 physikalischer Thread, bitte immer 1x2 bis nx2 konfigurieren... in einigen VMwarew Blogs stehts anders - 1 vCore wird auf die Rechenleistung eines pCores gemappt.
Das benche ich uach noch aus... mit 4 Sessions meiner Software, die 100% auf einem Core bringt hab ich halt nur vier der virtuellen Cores ausgelastet und ca. 50% der CPU-Kapazitäten lt VMware Monitoring. Und das zählt Corecount X Takt (nicht Threads)
bin aber etwas weiter - ich hab den Benchmark in Einzelschritte aufgegliedert, und nur einer hatte Laufzeiten, die sich mit Anzahl der parallelen Sessions erhöht hatte, bei 4 Sessions kam ich auf einen Faktor 2. Alle anderen Schritte hatten fast exakt dieselben Laufzeiten, solange der Host nicht überlastet war. Nur mit 3 VMs und jeweils 5 Sessions war das Ding total am Ende, und da wurde die Rechenzeit auch nicht mehr fair verteilt.
moin...
sach ich doch, da ist wohl die hardware am ende....
Frank
Nur mit 3 VMs und jeweils 5 Sessions war das Ding total am Ende, und da wurde die Rechenzeit auch nicht mehr fair verteilt.
sach ich doch, da ist wohl die hardware am ende....
Frank
Für mich klingt das nach wildem stochern im Nebel.
Ich würde erstmal HT aus machen. Dann würde ich mit einer VM mit 1 vCore die Laufzeit von was auch immer messen. Dann mit 7 VM zu je einem vCore die Laufzeit parallel messen (auf einem 8 pCore System). Dabei bleibt ein pCore für den Hypervisor frei denn der muss ja auch irgendwo rödeln. Eigentlich müssten dann 7 pCores voll durchziehen und der eine zwischendurch den Rest behandeln. Mit 8 VMs wird dann eine VM immer mal wieder warten müssen weil der Scheduler ab und zu dem Hypervisor Platz macht.
Alle Beobachtungen würde ich mit esxtop machen! Hier nochmal mehr Input dazu:
https://buildvirtual.net/troubleshoot-esxi-host-and-virtual-machine-cpu- ...
Es dürfte in dem Setup kaum %RDY Zeiten geben da ja eben nicht überbucht wurde. Aber in diesem Setup muss auch alles sauber durch laufen ohne komische Schwankungen in der Performance.
Ich hab den Xeon jetzt nicht angeschaut aber ich glaube da gab es noch keine CPUs die unterschiedlichen Turbo-Takt auf unterschiedlichen Kernen fahren, die müssten alle gleich hoch takten. Mit HT sieht die Welt eventuell anders aus, das muss man dann wiederholen.
SQL Laufzeiten sind so eine Sache. Der SQL Server optimiert Abfragen, vor allem wenn er Abfragen wiederholt und die vorher schon ausgeführt wurden. Außerdem lädt er Daten in den RAM, das kann die Laufzeit verzerren. Also bevor du mit SQL Querys "Messungen" betreibst solltest du die Querys nach jedem Reboot oder was auch immer ein paar mal laufen lassen und dann erst die Zeit nehmen.
Ich würde erstmal HT aus machen. Dann würde ich mit einer VM mit 1 vCore die Laufzeit von was auch immer messen. Dann mit 7 VM zu je einem vCore die Laufzeit parallel messen (auf einem 8 pCore System). Dabei bleibt ein pCore für den Hypervisor frei denn der muss ja auch irgendwo rödeln. Eigentlich müssten dann 7 pCores voll durchziehen und der eine zwischendurch den Rest behandeln. Mit 8 VMs wird dann eine VM immer mal wieder warten müssen weil der Scheduler ab und zu dem Hypervisor Platz macht.
Alle Beobachtungen würde ich mit esxtop machen! Hier nochmal mehr Input dazu:
https://buildvirtual.net/troubleshoot-esxi-host-and-virtual-machine-cpu- ...
Es dürfte in dem Setup kaum %RDY Zeiten geben da ja eben nicht überbucht wurde. Aber in diesem Setup muss auch alles sauber durch laufen ohne komische Schwankungen in der Performance.
Ich hab den Xeon jetzt nicht angeschaut aber ich glaube da gab es noch keine CPUs die unterschiedlichen Turbo-Takt auf unterschiedlichen Kernen fahren, die müssten alle gleich hoch takten. Mit HT sieht die Welt eventuell anders aus, das muss man dann wiederholen.
SQL Laufzeiten sind so eine Sache. Der SQL Server optimiert Abfragen, vor allem wenn er Abfragen wiederholt und die vorher schon ausgeführt wurden. Außerdem lädt er Daten in den RAM, das kann die Laufzeit verzerren. Also bevor du mit SQL Querys "Messungen" betreibst solltest du die Querys nach jedem Reboot oder was auch immer ein paar mal laufen lassen und dann erst die Zeit nehmen.
