Virtualisierung - Unterschied 2 Kerne mit 1 Thread oder 1 Kern und 2 Threads?

[PHuV]

Man kann bei den aktuellen Virtualisierern (Citrix Xen, VMWare, Oracle VirtualBox und Co.) pro VM einstellen, wieviel Kerne und wieviel Threads pro Kern verwendet werden.

Frage: Hat schon jemand mal hier getestet, ob das einen Unterschied macht? Ich habe beispielsweise einen Server mit Xen 7.1 und 2 x Xeon-X5650 drin, mit jeweils 6 Kernen und 12 Threads pro CPU, insgesamt also 12 Kerne/24 Threads.

Wäre es nun sinnvoller, einer VM 1 Kern + 2 Threads pro CPU zuzuweisen, oder 2 Kerne + 1 Thread pro CPU? Unterscheidet der Virtualisierer dies dann ebenso, und arbeitet hier CPU nah, oder ist das eh nur eine virtuelle Einheit, die erst mal nichts weiter aussagt, und sich generell nur an Kernen oder Threads orientiert?

Als weitere Info, es werden hier gemischt Windows und Linux-VMs verwendet, wobei ich den Linux-VMs hier 2 Kerne oder eben 1 Kern mit 2 Threads zuweisen möchte. Linux hat bekanntermaßen ein besseres Prozessverhalten als Windows, daher kann ich mir vorstellen, daß es unter Linux einen Unterschied machen könnte. Bisher habe ich aber immer nur mit Kernen gearbeitet, und die Threads auf Default 1 belassen.

 

[majusss]

Das würde mich auch mal interessieren. Benutze bisher auch immer nur 1 Thread.

 

[d4nY]

Du meinst Cores pro Socket oder nicht?

Und das ist afaik eher ein "Relikt" aus der Zeit, als Software noch nach Sockeln lizenziert wurde. Da konnte man dann eben einstellen, dass man z.B. 1 Socket mit 8 Cores nutzt (obwohl die unterliegende Hardware vielleicht 2 Sockets mit 4 Cores hatte). Mittlerweile gibt es aber für solche Software besondere Lizenzbedingungen für virtuelle Umgebungen oder es wird generell nach Kernen lizenziert (Datenbanken fallen mir da als Beispiel gerade ein)

Von der Performance her macht das keinen Unterschied würde ich sagen, Hyper-V bietet die Unterscheidung bspw. auch gar nicht an

 

[xexex]

VMware sagt - man soll wenn es nicht wegen irgendwelcher Lizenzbestimmungen anders notwendig ist, immer x CPUs mit einem Kern konfigurieren.

 

[majusss]

Es geht nicht um Sockel sondern Threads pro CPU. Ob man mit einer HT CPU (4/8) lieber 8/8 nimmt oder 4/8....

 

[xexex]

Es geht nicht um Sockel sondern Threads pro CPU.

Habe mit jetzt die Frage vom TE zig mal durchgelesen und ich glaube er wirft hier Kerne und Sockets durcheinander.

Grundsätzlich gilt weiterhin, bei VMware immer Sockets einstellen, außer man muss irgendwelche Beschränkungen umgehen.

Die Anzahl der zugewiesenen vCPUs darf auch in vielen Lastszenarien, die Anzahl der vorhandenen pCores überschreiten. Hyper-V behandelt jede vCPU als ein Thread und profitiert grundsätzlich von Hyperthreading. Bei VMware kann man das Verhalten noch zusätzlich steuern und bestimmten ob die vCPUs einer VM sich Threads eines Kerns mit anderen Maschinen teilen dürfen oder für sich nutzen. Hyperthreading hat hier Vorteile, weil eine Maschine bei einen Taskswitch auch mit der Hälfte der Kerne auskommt.

 

[PHuV]

Habe mit jetzt die Frage vom TE zig mal durchgelesen und ich glaube er wirft hier Kerne und Sockets durcheinander.

Nicht so ganz, ich habe mich immer an der CPU selbst orientiert, siehe Beispielsweise diese News:
https://www.heise.de/newsticker/mel...TFlops-3727268.html?wt_mc=rss.ho.beitrag.atom
Aber Du hast teilweise recht, weil in Citrix Xen heißt es genauer vCPU, socket und core, wobei das hier auch etwas verwirrend angegeben ist. Ich schließe mal aus dem Bild, daß vCPU hier = socket gilt.


Es gibt also die Möglichkeit 1 socket mit 2 Kernen oder 2 sockets mit jeweils einem Kern. Wenn ich Dich also richtig verstanden habe, ist die Option "2 sockets with 1 core per socket" die bessere Wahl? So habe ich es auch bisher immer verwendet.

 

[xexex]

Dann habe ich dich zumindest richtig verstanden.

Wie bereits erwähnt. Empfohlen wird dem Gast Sockel/vCPUs mit jeweils einem Kern zu präsentieren, wo dies möglich ist. Hintergrund ist hier, dass nur der Host die eigentliche Aufteilung der CPUs kennt und so am besten die Last aufteilen kann ohne mögliche "Optimierungen" durch das Gastsystem.

Allerdings will ich hier nicht einmal pauschalisieren. Die Empfehlung kommt aus der VMware Performance Guide, ich gehe hier nur vom vergleichbaren Hintergrund bei Xen.

When creating a virtual machine you have the option to specify the number of virtual sockets and the
number of cores per virtual socket. In general, we recommend leaving this at the default value of 1 core
per socket (with the number of virtual sockets therefore equal to the number of vCPUs).
In some cases, though, you might have non-technical reasons to set cores per virtual socket to a value
other than 1. For example, software is sometimes licensed on a per-socket basis, making it desirable to
have multiple cores per virtual socket.
If you do choose to configure more than one core per virtual socket, there are a few factors to keep in mind:
„ For wide virtual machines, be very careful about setting cores per virtual socket to a value other than
the default (1 core per socket). It's best to first try the default to determine what vNUMA size ESXi
selects for your virtual machine in your environment. Once you know the vNUMA size, use it to
choose a value for cores per socket.
For example, when running a 16-vCPU virtual machine on a host system with 10 cores per physical
socket, ESXi will select a vNUMA size of 8. Once this vNUMA size is known, you would configure
this virtual machine to have 8 cores per virtual socket.
„ For non-wide virtual machines, the number of cores per virtual socket is not as critical as for wide
virtual machines. On rare occasions, however, configuring cores per socket to a value other than 1
could influence guest CPU scheduling in either helpful or harmful ways. Careful testing is therefore
recommended before changing this configuration.
http://www.vmware.com/files/pdf/techpaper/VMware-PerfBest-Practices-vSphere6-0.pdf

 

[PHuV]

Update: Ne, Blödsinn geschrieben, Xen und VMWare unterscheiden sich doch, Xen verwendet Hypervisor-Technologie, VMWare verwendet OS-Virtualisierung. Hyper-V ist dagegen wieder Hypervisor.