14
Richtige Einstellungen beim ESXI 6.5 in Sachen CPU Zuweisung bei einer VM
Hallo Zusammen,
heute wollte ich mal fragen, wie ich eine VM die richtige Anzahl der von CPUs zuweise. Bin da ein wenig irritiert. Mein kleiner ESXI hat:
Wenn ich das richtig gelesen habe, ist das eine Multi-CPU mit 6 Kerne, wo bei jeder Kern zwei Thread kann. Ist es jetzt bei ESXI besser, nur echte Kerne als CPU zu zuweisen oder inkl. Threds? Was macht es aus, ob ich einem Win-10 / 2016 12 CPUs inkl. Thread zuweise oder nur 6 echte Kerne?
Zur Auswahl habe ich die auf jeden Fall:
Vieleicht mag mir jemand dazu was schreiben, lieben Dank
heute wollte ich mal fragen, wie ich eine VM die richtige Anzahl der von CPUs zuweise. Bin da ein wenig irritiert. Mein kleiner ESXI hat:
Wenn ich das richtig gelesen habe, ist das eine Multi-CPU mit 6 Kerne, wo bei jeder Kern zwei Thread kann. Ist es jetzt bei ESXI besser, nur echte Kerne als CPU zu zuweisen oder inkl. Threds? Was macht es aus, ob ich einem Win-10 / 2016 12 CPUs inkl. Thread zuweise oder nur 6 echte Kerne?
Zur Auswahl habe ich die auf jeden Fall:
Vieleicht mag mir jemand dazu was schreiben, lieben Dank
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: 441356
Url: https://administrator.de/contentid/441356
Ausgedruckt am: 08.11.2024 um 11:11 Uhr
14 Kommentare
Neuester Kommentar
Moin,
genau habe ich es nicht mehr im Kopf.
Hier lässt sich aber steuern, das ein normaler Kern und ein Hyperthreading Kern nicht auf dem selben physischen Kern liegen.
Das ist der grobe Sinn dahinter Sockel in einer VM zu definieren.
Des weiteren kann es Lizenz Gründe haben so eine Konfiguration vorzuhalten.
Eine Genaue Beschreibung seitens VmWare habe ich gerade nicht zur Hand.
Gruß
Spirit
genau habe ich es nicht mehr im Kopf.
Hier lässt sich aber steuern, das ein normaler Kern und ein Hyperthreading Kern nicht auf dem selben physischen Kern liegen.
Das ist der grobe Sinn dahinter Sockel in einer VM zu definieren.
Des weiteren kann es Lizenz Gründe haben so eine Konfiguration vorzuhalten.
Eine Genaue Beschreibung seitens VmWare habe ich gerade nicht zur Hand.
Gruß
Spirit
Hi,
das ist ein altes Thema und wurde schon oft im Web diskutiert. Such mal nach sowas wie
VMware vcpu hyperthreading sizing
o.ä.
E.
Edit:
Soweit ich mich erinnere, steuert VMware das automatisch. Man kann beim Zuweisen von vCPU nicht unterscheiden zwischen "echtem" Core und HT-Core. Aber VMware wird beim Zuteilen der Rechenzeiten pro VM immer darauf achten, dass die einzelnen vCPU, welche man einer VM zugewiesen hat, nach Möglichkeit immer auf anderen Kernen laufen. Solange es eben geht. Wenn die Hardware derart ausgebucht ist, dass es nicht mehr anders geht, dann kann es auch sein, dass eine VM eben mal doch während eines Zyklus den "echten" Core und den HT-Core benutzt. Bei nächsten Zyklus wird es dann wieder neu berechnet.
das ist ein altes Thema und wurde schon oft im Web diskutiert. Such mal nach sowas wie
VMware vcpu hyperthreading sizing
o.ä.
E.
Edit:
Soweit ich mich erinnere, steuert VMware das automatisch. Man kann beim Zuweisen von vCPU nicht unterscheiden zwischen "echtem" Core und HT-Core. Aber VMware wird beim Zuteilen der Rechenzeiten pro VM immer darauf achten, dass die einzelnen vCPU, welche man einer VM zugewiesen hat, nach Möglichkeit immer auf anderen Kernen laufen. Solange es eben geht. Wenn die Hardware derart ausgebucht ist, dass es nicht mehr anders geht, dann kann es auch sein, dass eine VM eben mal doch während eines Zyklus den "echten" Core und den HT-Core benutzt. Bei nächsten Zyklus wird es dann wieder neu berechnet.
Ok, verstanden. Der Groschen ist so weit gefallen. Es spielt also für die VM keine Rolle, weil eben nicht unterscheiden kann, was Kern oder Threads sind.
Na ja, dann sage ich einfach mal Danke und ich teste einfach mal ein wenig. Mal sehen wie sich der Terminal- Server 2016 verhält wenn ich ihm ab morgen 12 CPUs verpasse.
Na ja, dann sage ich einfach mal Danke und ich teste einfach mal ein wenig. Mal sehen wie sich der Terminal- Server 2016 verhält wenn ich ihm ab morgen 12 CPUs verpasse.
Ich würde je nach HW zwei Sockel machen sofern auch zwei CPUs Hardwareseitig verfügbar sind.
Zitat von @zeroblue2005:
Na ja, dann sage ich einfach mal Danke und ich teste einfach mal ein wenig. Mal sehen wie sich der Terminal- Server 2016 verhält wenn ich ihm ab morgen 12 CPUs verpasse.
Wenn das die einzige VM auf diesem ESX ist, dann wird das funktionieren. Wenn da aber noch mehr VM's drauf laufen, dann wird das nicht viel an Leistung bringen. Ein alter Grundsatz bei der Virtualisierung ist: Nicht in die Tiefe skalieren (mehr Ressourcen pro VM) sondern besser in die Breite (mehrere VM mit weniger Ressourcen). Sofern der bereitzustellende Dienst die Verteilung über meherer Server überhaupt zulässt bzw. es praktikabel ist.Na ja, dann sage ich einfach mal Danke und ich teste einfach mal ein wenig. Mal sehen wie sich der Terminal- Server 2016 verhält wenn ich ihm ab morgen 12 CPUs verpasse.
Hallo zusammen,
für die optimale Zuweisung von Ressourcen für eine virtuelle Maschine sind die Eigenschaften der Hardware ausschlaggebend. Bei einem Multi-CPU Server (z.B. 2x 6 Cores / 24 Thread, 256 GB RAM) bildet jede CPU einen NUMA (Non-Uniform Memory Access) Knoten. Wenn der Arbeitsspeicher auf dem Mainboard gleichmäßig verteilt ist, dann hat jeder NUMA Knoten 1 CPU und 128 GB RAM.
Der VMware NUMA schedularversucht stets eine virtuelle Maschine auf einen NUMA Knoten zu betreiben, sodass die bestmögliche Performance gewährleistet wird. Dies kann natürlich nicht realisiert werden, wenn einer virtuellen Maschine mehr CPU/Arbeitsspeicher zugewiesen wird als der NUMA Knoten zur Verfügung stellen kann. Stichwort over-provisiong. Eine Aufteilung auf die NUMA Knoten wird nicht automatisch durchgeführt, dies muss der VMware Administrator per Parameter numa.vcpu.maxPerMachineNode für die virtuelle Maschine eigenständig durchführen.
Wie @emeriks bereits richtig beschrieben hat unterscheidet VMware nicht zwischen echtem Core und HT-Core, es gibt einen Layer dazwischen mit dem Namen pCPU (VMkernel Layer). Dabei kann jeder pCPU einen echten Core oder einen HT-Core belegen, dies steuert der VMware NUMA schedular selbstständig.
Für ein besseres Verständis zu der Thematik kann ich das Optimize and Scale Dokument von VMware empfehlen.
Gruß, Sascha
für die optimale Zuweisung von Ressourcen für eine virtuelle Maschine sind die Eigenschaften der Hardware ausschlaggebend. Bei einem Multi-CPU Server (z.B. 2x 6 Cores / 24 Thread, 256 GB RAM) bildet jede CPU einen NUMA (Non-Uniform Memory Access) Knoten. Wenn der Arbeitsspeicher auf dem Mainboard gleichmäßig verteilt ist, dann hat jeder NUMA Knoten 1 CPU und 128 GB RAM.
Der VMware NUMA schedularversucht stets eine virtuelle Maschine auf einen NUMA Knoten zu betreiben, sodass die bestmögliche Performance gewährleistet wird. Dies kann natürlich nicht realisiert werden, wenn einer virtuellen Maschine mehr CPU/Arbeitsspeicher zugewiesen wird als der NUMA Knoten zur Verfügung stellen kann. Stichwort over-provisiong. Eine Aufteilung auf die NUMA Knoten wird nicht automatisch durchgeführt, dies muss der VMware Administrator per Parameter numa.vcpu.maxPerMachineNode für die virtuelle Maschine eigenständig durchführen.
Wie @emeriks bereits richtig beschrieben hat unterscheidet VMware nicht zwischen echtem Core und HT-Core, es gibt einen Layer dazwischen mit dem Namen pCPU (VMkernel Layer). Dabei kann jeder pCPU einen echten Core oder einen HT-Core belegen, dies steuert der VMware NUMA schedular selbstständig.
Für ein besseres Verständis zu der Thematik kann ich das Optimize and Scale Dokument von VMware empfehlen.
Gruß, Sascha
Einem virtuellen Server alle verfügbaren CPUs eines Hosts zu verpassen, ist keine gute Idee. Denn die VM bekommt nur dann Rechenzeit, wenn gerade alle von ihr benutzen Cores einen freien Rechen-Slot bekommen. Da auch der ESXi-Kernel damit auskommen muss, wird diese VM zwar funktionieren, aber Spaß macht das nicht.
Im Normalfall braucht keine VM mehr als 4 VCPUs, Ausnahmen sind extrem heftige Datenbankserver und so'n Zeugs. Aber ein TS kommt prima mit weniger aus.
Im Normalfall braucht keine VM mehr als 4 VCPUs, Ausnahmen sind extrem heftige Datenbankserver und so'n Zeugs. Aber ein TS kommt prima mit weniger aus.
Sowas kann man nicht pauschalisieren. Unsere haben 8 vCPU, ohne Überbuchung der physischen Kerne, und selbst das kann eng werden. Das hängt von den Anwendungen ab und was die Anwender gerade machen und wir diese Anwender gerade auf die TS verteilt sind.
Ok, danke das werde ich berücksichtigen. Habt Recht und klingt logisch. Wieviel CPUs würdet Ihr einen Exchange 2016 auf 2016 geben? Ich habe dieses derzeit auf 20 GB RAM und 4 CPUs eingestellt.
Auf dem Terminal 2016 laufen massig Access Datenbanken. Derzeit habe ich diesen auf einem älteren ESXI am laufen, mit einem I7 6700 mit 4 CPUs und 20 GB RAM. Bei ca. 15-20 Benutzern ist das manchmal echt zu wenig. Die Auslastung liegt laut Taskm. CPU bei 70-80 % und RAM ebenfalls.
Ich werde diesen über Ostern auf den neuen ESXI verschieben. Und erhoffe mir durch die bessere Host Hardware, dass hier Besserung eintritt.
Auf dem Terminal 2016 laufen massig Access Datenbanken. Derzeit habe ich diesen auf einem älteren ESXI am laufen, mit einem I7 6700 mit 4 CPUs und 20 GB RAM. Bei ca. 15-20 Benutzern ist das manchmal echt zu wenig. Die Auslastung liegt laut Taskm. CPU bei 70-80 % und RAM ebenfalls.
Ich werde diesen über Ostern auf den neuen ESXI verschieben. Und erhoffe mir durch die bessere Host Hardware, dass hier Besserung eintritt.
Hallo,
schau dir die Auslastung (CPU, RAM, etc.) am besten mittels esxtop direkt auf dem ESX-Host an.
Für einen Exchange Server 2016 auf einem Windows Server 2016 sind die Requirements von Microsoft eigentlich sehr gut angegeben.
Ohne zu wissen wie viele Postfächer in Zukunft auf dem Exchange Server betrieben werden, mein Vorschlag starte mit 32 GB Arbeitsspeicher und 4 vCPUs. Bei Bedarf den Arbeitsspeicher potentiell erhöhen (48 GB, 64 GB) sofern es zu Engpässen kommen sollte. Dies im Vorfeld entsprechend analysieren (siehe esxtop Link).
Welche Zahl verbirgt sich hinter massig? 10,20,30,50?
Gruß, Sascha
schau dir die Auslastung (CPU, RAM, etc.) am besten mittels esxtop direkt auf dem ESX-Host an.
Für einen Exchange Server 2016 auf einem Windows Server 2016 sind die Requirements von Microsoft eigentlich sehr gut angegeben.
Ohne zu wissen wie viele Postfächer in Zukunft auf dem Exchange Server betrieben werden, mein Vorschlag starte mit 32 GB Arbeitsspeicher und 4 vCPUs. Bei Bedarf den Arbeitsspeicher potentiell erhöhen (48 GB, 64 GB) sofern es zu Engpässen kommen sollte. Dies im Vorfeld entsprechend analysieren (siehe esxtop Link).
Welche Zahl verbirgt sich hinter massig? 10,20,30,50?
Gruß, Sascha
Hallo Sascha,
Ok, der Exchange läuft schon seit zwei Jahren. Derzeit sind sind ca. 60 Postfächer. Mit Extop, kann ich das jetzt nicht messen, jedoch in der Wwb-Gui vom ESXI steht, für die letzten 60 Min.
Auf dem TS sieht das so aus, 10-20 mdbs sind ständig geöffnet.
Komisch finde ich es manchmal nur, dass mir der Taskm. Von Windows oft viel höhere Auslastungen anzeigt, als der ESXI
Ok, der Exchange läuft schon seit zwei Jahren. Derzeit sind sind ca. 60 Postfächer. Mit Extop, kann ich das jetzt nicht messen, jedoch in der Wwb-Gui vom ESXI steht, für die letzten 60 Min.
Auf dem TS sieht das so aus, 10-20 mdbs sind ständig geöffnet.
Komisch finde ich es manchmal nur, dass mir der Taskm. Von Windows oft viel höhere Auslastungen anzeigt, als der ESXI
Meine TS haben tatsächlich auch 8 vCPU und können die gut brauchen. Es sind auch pro TS schon 15+ User mit fiesen Aplikationen unterwegs. Aber wichtig wie schon geschrieben nie alle vCPUs eines Servers und besser nur das maximum für optimales NUMA. Alle anderen VMs kommen häufig mit wenig aus.
Mein Exchange 2013 braucht nur 2 vCPU und läuft gut mit 35+ Postfächern, das ist aber bei Exchange 2016 vermutlich nicht mehr ausreichend.
Mein Exchange 2013 braucht nur 2 vCPU und läuft gut mit 35+ Postfächern, das ist aber bei Exchange 2016 vermutlich nicht mehr ausreichend.
... na ja, zwischen EX 2013 und 2016 ist der Unterschied ja jetzt nicht so groß. Ich glaube ich setze meinen auch mal auf 2 CPUs. Mal sehen was passiert.
So, habe mal alles wie beschrieben umgestellt, man will es kaum glauben, aber jetzt läuft es wesentlich besser! Muss aber auch zugeben, dass ich am RAID.Controller auch Änderungen vorgenommen habe.
Hierzu habe ich auch noch mal eine Frage, aber ist kein Thema für diesen Beitrag, daher mache ich mal einen neuen auf!
Danke euch...
Hierzu habe ich auch noch mal eine Frage, aber ist kein Thema für diesen Beitrag, daher mache ich mal einen neuen auf!
Danke euch...
