6
Hyper-V 2016 - CPU auf Gast-Betriebssystem optimieren
Hallo zusammen
Ich habe hier einen Hyper V Server, wo ich ein Gast-OS habe, deren DB-Applikation nur begrenzt Hyperthreading-tauglich ist. Ich würde gerne 4 virtuelle Sockets auf eine CPU legen, um somit die Leistung auf eine CPU auf dem Gast-OS zu optimieren. In ESX kann ich wählen, ob ich physische CPUs oder Sockets hinzufügen möchte. Gibt es in Hyper-V Srv 2016 ebenfalls die Möglichkeit, diese Einstellung vorzunehmen? In den Settings der VM habe ich nichts gefunden...
Gruss Hijacker
Ich habe hier einen Hyper V Server, wo ich ein Gast-OS habe, deren DB-Applikation nur begrenzt Hyperthreading-tauglich ist. Ich würde gerne 4 virtuelle Sockets auf eine CPU legen, um somit die Leistung auf eine CPU auf dem Gast-OS zu optimieren. In ESX kann ich wählen, ob ich physische CPUs oder Sockets hinzufügen möchte. Gibt es in Hyper-V Srv 2016 ebenfalls die Möglichkeit, diese Einstellung vorzunehmen? In den Settings der VM habe ich nichts gefunden...
Gruss Hijacker
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: 393810
Url: https://administrator.de/forum/hyper-v-2016-cpu-auf-gast-betriebssystem-optimieren-393810.html
Ausgedruckt am: 23.12.2024 um 10:12 Uhr
6 Kommentare
Neuester Kommentar
Warum 4vcpu, wenn die DB nur begrenzt ht fähig ist?
Und auf deine Frage, nein, geht nicht.
Und auf deine Frage, nein, geht nicht.
Hallo,
du möchtest also die virtuelle CPU so konfigurieren, dass es für die VM so aussieht als sei es ein Core, sind das dieser eine Core aus mehreren realen Cores gepoolt wird, also quasi ein Core-Cluster?
Das geht nicht. Wenn die Anwendung nicht damit klar kommt, ihre Tätigkeit auf mehrere Threads zu verteilen, müssen die Programmschritte eben nacheinander auf einem Prozessorkern abgearbeitet werden. Um hier die Performance zu Steigern muss der Core schneller rechnen. Das kann er aber nicht, auch nicht mit mehreren Threads dahinter.
Stell dir das am besten analog zum trunking/teaming von Netzwerkschnittstellen vor. Das ist auch nur Scheller, wenn der Netzwerkverkehr an mehrere unterschiedliche Ziele rausgeht. Die Übertragung 1:1 wird nicht schneller.
Kläre aber erst mal, wo der Flaschenhals der Anwendung liegt. Oft sind es die Schreibzugriffe auf die Platte und nicht die CPU.
Grüße
lcer
du möchtest also die virtuelle CPU so konfigurieren, dass es für die VM so aussieht als sei es ein Core, sind das dieser eine Core aus mehreren realen Cores gepoolt wird, also quasi ein Core-Cluster?
Das geht nicht. Wenn die Anwendung nicht damit klar kommt, ihre Tätigkeit auf mehrere Threads zu verteilen, müssen die Programmschritte eben nacheinander auf einem Prozessorkern abgearbeitet werden. Um hier die Performance zu Steigern muss der Core schneller rechnen. Das kann er aber nicht, auch nicht mit mehreren Threads dahinter.
Stell dir das am besten analog zum trunking/teaming von Netzwerkschnittstellen vor. Das ist auch nur Scheller, wenn der Netzwerkverkehr an mehrere unterschiedliche Ziele rausgeht. Die Übertragung 1:1 wird nicht schneller.
Kläre aber erst mal, wo der Flaschenhals der Anwendung liegt. Oft sind es die Schreibzugriffe auf die Platte und nicht die CPU.
Grüße
lcer
Wenn sowas möglich wäre, müsste man sich als Entwickler nicht mehr den Arsch aufreißen wg. multithreading etc.
Daher leider nein, man kann nicht aus vier physischen CPUs eine schnellere virtuelle machen
Daher leider nein, man kann nicht aus vier physischen CPUs eine schnellere virtuelle machen
Danke für den Input. Die Schreibperformance liegt bei 350-400 MB/Sec (aus der VM getestet.)
Zitat von @hijacker99:
Danke für den Input. Die Schreibperformance liegt bei 350-400 MB/Sec (aus der VM getestet.)
Danke für den Input. Die Schreibperformance liegt bei 350-400 MB/Sec (aus der VM getestet.)
Das sagt nicht viel. https://de.m.wikipedia.org/wiki/Input/Output_operations_Per_Second
Grüße
lcer
Hi,
Das hatte - meines Wissens - eher lizenztechnische Gründe als leistungstechnische. (Lizenztechisch für die im Gast betriebenen Anwendungen)
Inzwischen kann man das bei VMware auch nicht mehr auswählen. Zumindest nicht über VCenter und Web Client. Oder? (v6)
Über mehrere Sockets läuft eine Anwendung, welche viele Daten schaufelt, höchstwahrscheinlich sogar langsamer. Von daher sollte man eine VM schon so lange wie möglich auf einem Socket laufen lassen. VMware versucht das automatisch, solange wie es geht. Bei Hyper-V habe ich keine Ahnung, vermute aber das gleiche.
Damit steuert man aber auch bei VMware nicht, dass eine VM keinen HT-Core bekommen soll/kann/darf.
Wenn die Anwendung im Gast kein HT kann (Woran machst Du das eigentlich fest?), dann könntest Du schon in der Hardware das HT deaktivieren. Das gilt dann aber für alle VM dieses Host, ist klar.
E.
Das hatte - meines Wissens - eher lizenztechnische Gründe als leistungstechnische. (Lizenztechisch für die im Gast betriebenen Anwendungen)
Inzwischen kann man das bei VMware auch nicht mehr auswählen. Zumindest nicht über VCenter und Web Client. Oder? (v6)
Über mehrere Sockets läuft eine Anwendung, welche viele Daten schaufelt, höchstwahrscheinlich sogar langsamer. Von daher sollte man eine VM schon so lange wie möglich auf einem Socket laufen lassen. VMware versucht das automatisch, solange wie es geht. Bei Hyper-V habe ich keine Ahnung, vermute aber das gleiche.
Damit steuert man aber auch bei VMware nicht, dass eine VM keinen HT-Core bekommen soll/kann/darf.
Wenn die Anwendung im Gast kein HT kann (Woran machst Du das eigentlich fest?), dann könntest Du schon in der Hardware das HT deaktivieren. Das gilt dann aber für alle VM dieses Host, ist klar.
E.
