Was ist für VMS entscheidend(er) die Anzahl von cores/Threads oder pro-core IPC?

Reflexion

Lieutenant
Registriert
Dez. 2009
Beiträge
634
N'Abend zusammen,

eine Frage die ich mir bereits längere Zeit beschäftigt, auch wenn sie wohl eher mit " es kommt drauf an"... zu beantworten ist, was macht ganz pauschal beantwortet ( ...in Verwendung von unRAID/Proxmox..FreeNAS..Hyper-V usw.) mehr Sinn, bei Verwendung von VMs (zbs Windows 10+ GPU pass.) eher getrennte threads (mit CPU pinning) oder wenige Kerne mit möglichst hohen Takt und IPC wie es bei Intels Xeon und den letzten beiden Generationen seitens AMD Ryzen der Fall ist?
Hier könnte man mehrere VMs auf ein thread setzen, numa knoten in hyper-v wäre auch noch eine Möglichkeit für Aufteilung.

Persönlich stelle ich mir die Frage weil viele Threads der Xeons V3/4 mittlerweile günstig zu haben sind im Einklang mit ECC-REG RAM. Aber günstig dann nur wenn der pro core Takt niedrig ausfällt, Xeons der E3 lasse ich jetzt mal ausgenommen.

Vielen Dank.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: M-X, SpicyWolf und Nero FX
Ach man, Erfahrungswerte wären eine Hilfe für Entscheidungen.^^
 
Was kommt da drauf an? Wenn es um Isolation geht, wenn interessieren da Core spezifische Dinge?
Warum sollte man mehr als eine vm auf einen thread setzen? Dann hätten wir auch bei Singlecore CPU bleiben können. Ein thread per vm ist schon absolutes Minimum.

Verstehe das Problem nicht. Numa sollte eigentlich auch kein Thema sein... aber gut, wenn man mehr als eine CPU verbaut, dann mag das interessant werden.
 
  • Gefällt mir
Reaktionen: Reflexion
..im Kern geht es mir um Erfahrungswerte da ich selbst noch nicht ausreichend Erfahrungen gemacht habe und Investition nicht unnötig schnell zur Einbahnstraße sich entwickeln sollen. Bei einer Proxmox Präsentation würde darauf hingewiesen auf möglichst hohen proKern Takt zu setzen, gut das ist dann evtl. auch keine Thematik die auf eine bastellei daheim abzieht.. Numa zbs weil man so 20€ Xeons v2/3 auf Dual Sockel Board setzen kann.
 
Zuletzt bearbeitet:
Reflexion schrieb:
..im Kern geht es mir um Erfahrungswerte da ich selbst noch nicht ausreichend Erfahrungen gemacht habe
Das hängt halt (wie Du ja selbst schon vermutest) ganz davon ab, was Du machst bzw. welche Anwendungen Du in den VMs fährst. Das lässt sich pauschal nicht beantworten.

Mal abgesehen davon wenn Du nicht in irgendwelche Grenzregionen kommst wo es auf jedes Quentchen Performance ankommt, dann gibts kaum einen großen Unterschied zwischen nem Ryzen und nem Xeon gleicher Klasse. Von daher macht es gar keinen Sinn da zu viel drüber nachzudenken.

Willst Du es dennoch machen, dann setze auf deinem jetzigen Rechner dein Wunschsetup auf und guck nach, wo die Performanceengpässe genau sind und wähle danach die Hardware aus.

Oder Du wirst mal in dem Konkreter was Du machen willst. Dann kann man Dir auch konkretere Hinweise geben.
 
  • Gefällt mir
Reaktionen: Reflexion
..konkreter ist so ne Sache 😭 ich weiß ja nicht was langfristig Ziel wird, darum wollte ich Eindrücke und Erfahrungswerte ja eben sammeln um selbst abzuschätzen, oder das zu erleichtern. Nur wenn ich auf Xeons setze, bin ich erstmal auf eine Plattform gefangen. Ryzen wäre hier besser, nur "pro" ist wenig verfügbar und darüber hinaus möchte ich gerne auf ECC Support setzen.
 
Reflexion schrieb:
ich weiß ja nicht was langfristig Ziel wird, darum wollte ich Eindrücke und Erfahrungswerte ja eben sammeln um selbst abzuschätzen, oder das zu erleichtern.
Wie gesagt. Fürs reine lernen und damit rumspielen ists letztlich wurscht. Fürs reine lernen und rumspielen macht nicht mal ein eigener Rechner Sinn.
 
Pinning würde ich persönlich nur verwenden, wenn ich weiß dass ich ohne nicht auskommen. Ist mir bis jetzt noch nie passiert. Wird vielleicht interessant wenn man was Richtung Echtzeit macht. CPU Kerne/Threads kann man auch ziemlich gut "Over Commiten", beim Ram wäre ich da schon vorsichtiger, wenn der voll ist geht gar nichts mehr.

Bei Windows VMs sollte man auch immer nur eine Sockel einstellen, mit mehrere Kernen/Threads, bei Linux ist das im normalen Gebraucht eigentlich egal.

Bei Linux ist es auch wichtig den Load im Auge zu behalten, das ist wichtiger aus die CPU Auslastung. Und dann halt schauen was laufen soll, laufen mehrere Anwendungen parallel, läuft eine Muilticore-Anwendung die gerne viel Resourcen verwendet (z.B. Videokompression), oder läuft nur ein Nginx drauf.
 
  • Gefällt mir
Reaktionen: Reflexion
Danke für die Hinweise, Erfahrungswerte, pinning habe ich bisher immer bei unRAID benutzt, müsste ich Mal testen ob es zum Nachteil sich entwickelt wenn dies nicht genutzt wird. Ich bin mit aber nicht sicher was Du mit "Load" meinst, worauf sich das bezieht.
 
Reflexion schrieb:
Noramlerweise bestimmt ja das Betriebssystem, welcher Prozess auf welcher CPU läuft. Dabei kann es auch während der Laufzeit zu dynamischen Verschiebungen kommen. Das beispielsweise die Ausführung eines Prozess auf eine CPU bzw. Kern verschoben wird, der gerade weniger belastet ist. Das System sorgt also für Lastverteilung.

Dieses verschieben geht aber nicht ohne Overhead. Und der kann (je nach Art des Prozesses) kann das durchaus signifikant sein. Insbesondere wenn das System aufgrund der Lastverteilung auf die Cores sehr viel hin und her schiebt.
Mit CPU-Pinning bindet man ja ein Prozess/Prozessgruppe/System an eine CPU und vermeidet dabei den Overhead (zumindest für den Prozess der gebunden ist).

Das vermeidet dann zwar den Overhead, aber führt auch dazu das die betroffene CPU bei der dynamischen Lastverteilung nicht dabei ist. Du lässt also ggf. Ressourcen brach liegen, wenn die gebundene CPU quasi nur im Leerlauf ist während die anderen vielleicht am ackern sind.

Deshalb lohnt sich das oftmals nur in speziellen Fällen. Wenn zum Beispiel ein Prozess cpu-lastig ist und das Verschieben daher besonders wehtun würde und man andererseits kaum was dadurch gewinnt, weil die gebundene CPU eher wenig im Leerlauf ist.

Reflexion schrieb:
unRAID ist ja so eine Dateifreigabe. Dateien hin und herschaufeln sind eher nicht so CPU-lastig. Pinning sollte sich also nicht lohnen (oder gar negativ sein). Es sei denn, die CPU macht im Zuge dessen noch ein paar zusätzliche Aufgaben (z.B: bei einem verschlüsselten Dateisystem).

Reflexion schrieb:
Ich bin mit aber nicht sicher was Du mit "Load" meinst
Das sind Last-Werte die man sich bei einem UNIX(-ähnlichen) System z.B. mit uptime
anzeigen lassen kann.
Dann komm dann so ne Ausgabe wie z.B.
11:49vorm. up 15:07, 2 users, load averages: 0,45 0,48 0,46
(unter Linux werden die aus dem Proc-Dateisystem gezogen: /proc/loadavg)

Du bekommst also drei Werte und die spiegeln die "Last" der letzten Minute bzw. der letzten 5 Minuten bzw. der letzten Viertelstunde wider.
Wobei jetzt hier Last nicht direkt meint, wie stark die CPU ausgelastet ist.
In einem Multiprozess-System läuft ja kein Prozess durchgehend. Geht ja auch gar nicht. Weil Du hast üblicherweise viel mehr Prozesse als CPUs/Kerne. Das Betriebssystem gibt den Prozessen also Rechenzeit und entzieht ihm die dann wieder um Rechenzeit dem nächsten Prozess zuzuteilen.

Der "load average" spiegelt eher die Anzahl der Prozesse wieder die gerade darauf warten CPU-Zeit zu bekommen.
Grob gesagt: Umso höher der Wert, umso "schlechter" (allerdings: umso mehr CPU/Kerne Du hast, umso höher darf der Wert auch werden; also grob +1 pro CPU/Kern).

Wobei kurzzeitige Lastspitzen eher kein Problem sind. Wenn Du aber über längere Zeit hohe Werte hast, dann kann das auf ein Lastproblem hindeuten (daher auch die Unterteilung der Werte in verschiedene Zeitspannen; damit Du halt siehst, ob Du grad nur kurzzeitig Last hast oder obs ein dauerhaftes Problem gibt).
 
  • Gefällt mir
Reaktionen: jb_alvarado und Reflexion
Hi Reflexion,
ich schließe mich meinen Vorrednern an. Es kommt im Detail auf die Anwendung an.
Aus Erfahrung kann ich ein bisschen was erzählen:

In der Arbeit wechselten wir vor ein paar Jahren von Vier-Sockel-Systeme auf Dual-Sockel-Systeme, trotzdessen der Takt im Schnitt um 0,5Ghz weniger war. Wir setzen auf VMWare. Gefühlt lief alles runder in der Domäne. Ich denke die shared Lanes zwischen den Sockets waren sehr beansprucht. Zu diesem Zeitpunkt waren die vCores deutlich überbelegt (ich glaub der Faktor war 5 oder 6). Für übliche Domain Services reicht sowas alle mal, ich bin da eher der Meinung lieber ein oder zwei Threads mehr als zu wenig.
Andererseits gibts es wiederrum Dienste wie ein Drittanbieter Spooler System mit Meldestände und Kst-Verwaltung. Die Software mag beides Takt und Kerne.
Wiederum hatten wir im Lager eine Software mit Datenbank (ich erinnere mich an dieser Stelle jetzt nicht mehr genau an den Verwendungszweck), welche weder von Threads noch von RAM profitierte, sondern rein auf Takt ging. Die war anscheinend so wichtig, dass damals extra ein Core i7 mit der damals höchst möglichen Taktrate angeschafft wurde.

Im privaten Umfeld nutze ich Hyper-V und verwende einen i3 mit 4 Cores und 3,6Ghz. Ich habe mit diesem eine Domänenumgebung zum testen und spielen am Laufen. Hier reichen pro VM 2 vCores (W10 läuft mit 4 besser). In Summe sind das 8 VMs mit jeweils 2 bis 4 Kernen belegt und der i3 stemmt das ohne weiteres.
Der Rest macht hier kein Bottleneck, da der RAM ausreichend vorhanden ist mit 32GB für meine Zwecke und die vDisks auf einer schnellen NVMe-SSD liegen (es gibt außerdem noch Unterschieden an den Formaten der virtuellen Festplatten).

Ich hoffe, ich konnte dir mit meinen Erfahrungen helfen.
VG
Krad
 
Numa in den Raum werfen aber mit dem Begriff Last nichts anfangen können... 😵

Ganz einfach.
Anzahl vms...
Anzahl der benötigten kerne...
Wie weit du bereit bist, es die Anwendungen zu lassen shared kerne zu nutzen. Wenn du es übertreibst wird es halt langsam.
Da gibt es keine Blaupause.
Wenn DU nicht weißt wo die Reise hingeht... Wir erst recht nicht.

Bei einem mehrsockel System wird auch noch der RAM wichtig.
Es ist z. B. Ungünstig einer vm mehr RAM zu geben als von der Kern Anzahl her günstig wäre. Also böses Bsp. 2 Core vm (10% der Max Cores) aber 50% des gesamten RAMs.
Da alles nur Spielerei und nicht produktiv.
Keine 500 Mitarbeiter da drauf arbeiten. Eh Humbug.

Durch amd... Nimmst du nen großen ryzen und gut. Ram Limit wurde ja auch dank AMD hoch gesetzt im consumer Bereich.

Du machst dir um Sachen ne Platte die du eh nie erreichen wirst.

Mfg
 
Vielen lieben Dank für die genommene Zeit insbesondere für die Erklärung und weitere Erläuterungen, andy_m4, aber auch für die geteilten Erfahrungswerte seitens MrKr4D. So etwas ist es was ich bei Wiki. eben nicht finde und dabei hilft Entscheidungen an mehr Faktoren abzuwägen, Community eben.

Mir war bewusst, dass es keine einfache pauschal gehaltene Antwort gibt, aber Erfahrungswerte aus dem Alltag/Hobby, Beruf können eben helfen. Die These war eher in Richtung Brainstorm gedacht, vlt war meine formulieren nicht gut.

Zu RalphS"...Warum sollte man mehr als eine VM auf einen thread setzen?..." Nun ein Grund könnte sein, dass der single core Takt/IPC ausreichend genug ist, um mehrere VMs unterzubringen und so günstigere Prozessoren genutzt werden können auch aus Leistungsaufnahme Sicht, trotz "boost" und zunehmend Abweichung vom Sweetspot, die Vermutung dahingehend kann aber auch falsch sein. Verwunderlich fand ich es aufgrund dieser Hinweise;

Bei Kommentare wie die von "Matthias80" lernt man mehr und mehr (die verbliebene) Kommentare von "Holt" zu schätzen/missen, sicher eine Person die wie ich Ihre Macken hat, aber bei der Anzahl von Kommentare und den gefühlten 24/7 Support kann das auch mal passieren, insbesondere dann, wenn einen der zu vermittelte Inhalt wichtig ist und man nicht einfach nur zeigen möchte wie doof "yxz" ist. Zugutehalten muss man da doch die Fähigkeit Fakten zu liefern und sich die Zeit zu nehmen wirklich gut zu Begründen, auf Fragen einzugehen und das Besondere, ganz ohne Smiley und nur selten mit Provokation.(Ich weiß IT'ler neigen dazu, zumindest aus meiner Erfahrung).

Jemanden so an den Pranger zu stellen ist nicht meine liebste Eigenschaft aber;
Der Kommentar von "Matthias80" ist das worauf ich kein Bedarf habe, es hilft zumindest mir nicht weiter.
Bspw. ist unRAID und Ryzen nicht die beste Kombi. Die Auswahl die mit ECC "offiziell" daher kommt, von der ist auch wenig vorhanden, 500ter Boards teuer die für Serveranwendungen gut sind.
 
Zuletzt bearbeitet:
War nicht abwertend oder gar persönlich gemeint. Wenn das so rüber kam. Dickes sorry.
Erste wichtige Frage. Was du überhaupt vor hast... Wusstest du selbst noch nicht.
Da ist es einfach verdammt schwer überhaupt was zu sagen.

Hatte für meinen großen lange Zeit nen unraid mit zwei Windows, zwei gpu, zwei Monitoren ect. Zu laufen.

Von der Arbeit her viel vmware, hyper-v und xen hypervisor.

Krass das du dich an der einen Bemerkung so hochziehst...

Danach kommen ja doch kurz und knapp viele Infos.

Wo geht die Reise nun hin?
Hast du dir jetzt nen Plan gemacht?

Mfg
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Reflexion
Kleine Anmerkung an die Leute die sagen lieber gebe ich der VM paar Cores mehr als zu wenig. Das kann schnell kontraproduktiv werden Stichwort CPU Ready Time. Vereinfacht gesagt gewährt der physikalische Prozessor jeder virtuellen CPU Zugriff auf diesen selbst wenn die VPU nichts macht das führt dazu das VMs die evtl. CPU Power benötigen diese verspätet bekommen. Natürlich spielt das erst ab einer gewissen Anzahl an VMs eine immer bedeutendere Rolle.
 
  • Gefällt mir
Reaktionen: Reflexion
Zurück
Oben