Wird eine CPU im höheren Lastbereich merklich langsamer/ineffizienter?

AliManali

cpt sunday flyer
Thread Starter
Mitglied seit
07.03.2012
Beiträge
5.079
Ort
Ostschweiz
Hi

Habe atm eine 16 Core CPU im ESXi. Da dürften die Kerne so 1:4 überbucht sein. Da liegt immer eine Last von ca. 55% an. Unglaublich was da alles drauf tuckert. Auch DX Gameclients, wo 3D durch die CPU berechnet wird (nicht direkt zum spielen, mehr als Server und Zubehör).

Was mir dabei auffällt: wenn ich bisschen in anderen/neuen Gästen am experimentieren bin, geht es dann aber schnell Richtung >80% Load.

Frage ich mich halt, ob die CPU im höheren Lastbereich schlechter skaliert. Weil das was ich da mache, steht in keinem Vergleich zu dem was eh schon tuckert bei 55% Last. Wirklich Einbussen habe ich noch nicht, im Sinne dass es hakelig wird in der Bedienung, oder dass die Server grössere Latenzen hätten.

Aber habe doch mal eine E5-2699A v4 bestellt. Hoffe kriege da dann die Grundlast auf 30-35%, dass ich da noch bisschen spatzig habe.

Gruss und danke
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ja. Aber nicht, wenn viele Kerne gleichzeitig belastet werden. Hatte auf der Plattform mit einer 6 Core begonnen. Da musste ich den einzelnen Kernen CPU Zeit klauen, dass die nicht den ganzen Host sinnlos ausgelastet haben. Habe auch 256 GB RAM im System, die Lanes brauche ich auch. Sprich ein Ryzen ist da keine Option. Auch preislich nicht, alle Systeme laufen auf LGA 2011-3 (bald vier, plus Ersatzteile).

Ich habe auch nicht gefragt, ob es leistungsfähigere CPUs gibt als die E5-2699A v4. Das steht doch gar nicht zur Debatte bei der Frage. Ausserdem würde ich bei Deiner 12 Core Ryzen wieder vor dem Problem stehen, dass sich einzelne Anwendungen den ganzen Kern schnappen, nur weil sie können. Das brauche ich aber nicht. Sprich ich müsste die Leistung der einzelnen Threads wieder per Software beschränken. Anwendungen die sich ganze Threads schnappen sind die genannten Game Clients. Ob die nun mit 10 oder 5 fps laufen, ist mir völlig wumpe.

Aber schön, dass Du einen Benchmark gefunden hast, der mit meiner 10 Jahre alten Plattform offensichtlich den Boden aufwischen würde. Und dass Du mir offensichtlich nicht folgen kannst. Sonst würdest Du auf meine Fragen eingehen. Lass mich raten, Du hast keinen Plan, über was ich hier fabuliere?

Würde meinen, ohne endlos Tweaken würd Dein 9900X ganz schön in die Knie gehen im Gegensatz zu meiner Uraltplattform, wo ich eh nur PIII/PIV Spili hoste.
 
Zuletzt bearbeitet:
Ein aktueller Threadripper wird damit auch den Boden aufwischen, was war nochmal die Frage?
 
Du, wenn würde ich einen Epyc nehmen. Wüsste nicht, was für eine Consumer Plattform sprechen würde bei meinem Server.

Kann bitte noch wer was sinnvolles beitragen? Und mit sinnvoll in dem Zusammenhang meine ich weder Ryzen (omg), Threadripper oder Epyc. Bleiben wir doch bitte bei meiner C612 Plattform, danke.
 
Zuletzt bearbeitet:
Gehen wir mal davon aus, das Du mit 256 GB ausreichend Ram hast, und die VMs nicht swappen müssen. Dann wäre die CPU Auslastung die nächste Komponente, und eben auch der Zugriff auf Storage. In Bezug auf mögliche Flaschenhälse würde mir folgendes einfallen:

1)
Der Storage Durchsatz limitiert, z.B. weil HDDs mit hohen Latenzen ODER allgemein vom Durchsatz, den sich alle VMs teilen.
Mögliche Lösung: Datacenter SSDs mit PCIe/NVMe Anschluss.

2)
Es kann sein, das Deine Software primär als Single Core Task läuft, weil sie nicht auf Multi Core optimiert programmiert/optimiert ist und dementsprechend nicht mit der Anzahl der Kerne skaliert. Das ist leider ein bekanntes Problem, insbesondere bei alter Software. Würde in Deinem Fall bedeuten, das die Anwendungen mit einer CPU die zwar weniger Kerne hat, aber höherem maxmalen Takt läuft, unte dem Strich performanter läuft. Der limitierende Faktor ist immer die max. TDP der CPU - entweder viele Kerne die langsamer laufen, oder weniger Kerne die mehr max. Takt fahren. Und es kann auch sein, das Anwendungen von größerem L2/L3 Cache überproportional profitieren. Das kann man aber nicht pauschal vorhersagen, sowas muss man ausprobieren, welche Konstellation bei Deiner Software die beste Performance liefern.
 
Ja, SSDs sind natürlich alles SATA. Ist mir schon klar, dass Storage Nr1 der Showstopper ist. Meine Gäste halten sich allerdings zum Grossteil im RAM auf. Sind aber durchgängig alles Datacenter SSD, welche die Gäste von napp-it dem Host zurück gegeben. Bin übrigens ganz erstaunt, was so paar poplige MU/RI SATA SSD alles stemmen können. Noch nicht lange her, ist alles auf einer einzigen SM 883 getuckert. Mittlerweile habe ich 4 DC SSD für die Gäste an napp-it. Aber sehe da kein Storage Problem. Auch nicht wenn ich alles neu starte. Komme da gar nicht hinterher, mich überall durchzuklicken und die betreffenden Passwörter ein zu tippen.

Die VMs swappen auch alle nicht, die haben alle genügend zugewiesenen RAM.

Ja genau. Habe Software, die nimmt sich ST was sie kriegen kann. Ob die nun bisschen langsamer läuft, ist mir total wumpe. Aber wenn ich der VM 4 Threads zuweise, dann nimmt sie sich halt auf 2 Threads, was sie kriegen kann. Denke also, habe da definitiv bei der CPU das Problem. Konkret geht es da um drei VMs:

  • DCS World Server Win 11: die macht durchgängig Last. Auch beim RAM ist die nicht bescheiden. Habe 6 Cores und 32 GB RAM zugewiesen.
  • FSX FSOpen: da muss ich leider zu der Server Software noch den FSX Client laufen lassen. Der nimmt sich halt auf einem Thread, was er bekommen kann. Hier 4 Cores und paar GB RAM.
  • Für Phoenix RC habe ich immer 1-2 Gameclients auf separaten Gästen am laufen. Die nehmen sich jeweils auf einem Thread, was sie kriegen können. Auch hier 3-4 Cores und paar GB RAM
  • Der Rest sind halt die restlichen Server. Die machen aber eigentlich so gut wie gar keine Last auf der CPU. Auch hier massig RAM und meist so 2-4 Cores
Meist laufen halt so idk 10-15 VMs. CPU so 1:3 bis 1:4 überbucht, die meisten Kerne in den Gästen langweilen sich dabei.

Geht mir halt echt mehr um die CPU Auslastung. Wie gesagt, bislang läuft es nicht hakelig, oder die Server hätten grössere Latenz. Geht mehr darum, die CPU Load runter zu kriegen. Gerade auch, wenn ich am basteln bin. Sonst läufts ja ganz gut.
 
Zuletzt bearbeitet:
Hmm. Auf den einfachsten O-Ton übersetzt ;)
Du meinst also, daß schon allerlei auf dem Host passiert und du eine Last von 55% hast und dann spielst du dran rum und erzeugst (DIR NACH) eigentlich minimal mehr Last und die Auslastung schnellt dann aber auf 80%. Was du irgendwie zuviel anhand von dem was du machst, findest. Ist das innerhalb der 2 Zeilen so richtig?
 
Zuletzt bearbeitet:
Aber nicht, wenn viele Kerne gleichzeitig belastet werden.
Warum? Mit einer Core mehrere Threads bedienen ist nicht so das Problem, einen Thread auf mehrere Cores aufteilen aber eher nicht... vielleicht wegen dem folgenden Punkt..
Ausserdem würde ich bei Deiner 12 Core Ryzen wieder vor dem Problem stehen, dass sich einzelne Anwendungen den ganzen Kern schnappen, nur weil sie können.
Tun sie das? Cores für die VM fest zugewiesen meinst du? Sollte doch eigentlich nicht möglich sein, dass sich "eine Anwendung eine Core schnappt", da steh ich etwas auf der Leitung.
Mit ESXi kenn ich mich nicht aus, aber ich hatte zumindest mit Proxmox noch nie den Fall, dass sich ein Prozess "eine Core schnappt, nur weil sie kann"... steh da bissl auf der Leitung.
Aber wenn das bei deinen Anwendungen (FlugSim etc.) so ist, dann wird das so sein, kannte ich bisher nicht in diesem Ausmaß...
Frage ich mich halt, ob die CPU im höheren Lastbereich schlechter skaliert. Weil das was ich da mache, steht in keinem Vergleich zu dem was eh schon tuckert bei 55% Last.
Ich denke, das liegt vllt. daran, dass die 55% ja keine "dauerhaften" 55% sind, sondern 55% im Durchschnitt, du also durchaus Spitzen hast, wos hoch geht. Und wenn du auf 70-80% bist, treffen die Spitzen halt öfter/schneller die Decke, sozusagen.

Zudem bin ich nicht sicher, wie genau das Monitoring wirklich ist... also eben diese Spitzen betreffend.

Ich kann mir schon vorstellen, dass sich gerade "Single-Thread-Spitzen" recht ungünstig auswirken bzw. anfühlen können, es sind zwar viele Cores, dafür aber nicht besonders schnell (und ja auch nicht gerade sehr modern)... gerade wenn man neue VMs installiert und die da mehr tun müssen, ist das vllt. gerade eine solche Last?
 
Geht mehr darum, die CPU Load runter zu kriegen.
Aber warum? Bzw, zu welchem Zweck?
Vielleicht verstehe ich dein Vorhaben nicht so ganz. Du hast heute 16 Kerne und diese sind kumuliert bei ~50% Last, aber das alleine sagt ja wenig aus. Denn die 50% können zusammenkommen durch eine gleichmäßige Auslastung aller Kerne zu 50% ihrer Leistung oder eben (was offenbar eher deinen Fall beschreibt) weil acht Kerne Vollgas geben und die anderen sich langweilen.
Wenn du jetzt die CPU durch eine (leistungstechnisch identische, da gleiche Architektur und gleiches Taktverhalten) CPU mit 6 Kernen mehr ersetzt, wird das Bild nicht anders aussehen: acht Kerne geben Vollgas, die anderen (dann 14) langweilen sich. Ergibt dann im Durchschnitt ~36% CPU Load - aber wie gesagt halt einfach nur deshalb, weil sich mehr Kerne als zuvor langweilen.
 
Vielleicht verstehe ich dein Vorhaben nicht so ganz. Du hast heute 16 Kerne und diese sind kumuliert bei ~50% Last,
Er hat die Vermutung bzw. das Gefühl bzw. die Beobachtung gemacht, dasss sich die "oberen 50% schneller verbrauchen" "als die unteren 50%", wenn ich das richtig verstehe. Und die Frage ist eben, warum das so sein könnte.
Ergibt dann im Durchschnitt ~36% CPU Load - aber wie gesagt halt einfach nur deshalb, weil sich mehr Kerne als zuvor langweilen.
Vllt. ist das besser bei seinen Programmen mit dem "speziellen verhalten" die zugewiesene Rechenleistung auch auszunutzen...?
Müsste man halt probieren.


Ansonsten wurde ja schon viel gesagt, die Rohleistung pro Core ist bei den alten CPUs halt überschaubar, in knapp 10 Jahren hat sich doch was getan, wäre traurig, wenn nicht.
 
Er hat die Vermutung bzw. das Gefühl bzw. die Beobachtung gemacht, dasss sich die "oberen 50% schneller verbrauchen" "als die unteren 50%", wenn ich das richtig verstehe. Und die Frage ist eben, warum das so sein könnte.
Dann werfe ich mal eine Vermutung in den Ring: Im niedrigen Lastbereich taktet eine CPU niedriger und hat daher mehr Luft nach oben als wenn der Turbo schon anliegt und dann ausgefahren wird.

Vllt. ist das besser bei seinen Programmen mit dem "speziellen verhalten" die zugewiesene Rechenleistung auch auszunutzen...?
Also, unter der Prämisse, dass die CPUs die selbe Architektur besitzen und den selben Turbo-Takt bereitstellen (was ich bei Broadwell einfach mal unterstelle), kann ich mir das nicht vorstellen. Wenn ein Programm zu 100% im Singlecore-Leistungslimit hängt, spielt die über alle Kerne kumulierte durchschnittliche CPU-Load keine Rolle.
 
Hallo Leute,
Es wundert micht, dass hier keiner das Problem von Kontext Switchen und der Warteschlange angespprochen hat.

TL;DR: Mit steigender Überbuchung bzw.Last sinkt die gesamteffizienz bzw. nutzbare CPU-Zeit für die Gäste, kommen Gäste mit vielen vCPUs dazu die sie nicht brauchen vergrößert sich das Problem zusätzlich.

Das heißt, jeder Kern bzw. Thread kann nur einen Prozess bzw. eine VM gleichzeitig bedienen. Soll er was anderes machen, muss er den Kontext wechseln, was Zeit kostet in der keine Leistung, aber Arbeit verrichtet wird. Viele Kontextswitche bedeuten, dass die CPU mehr Zeit mit sich selbst beschäftigt ist.
Für ESXi (und sicherlich auch QEMU/KVM) gilt, dass ein Gast erst dann aktiv auf der CPU ausgeführt wird, wenn ihm echte Cores/Threads für alle zugewiesenen vCPUs bereit stehen. Das heißt, wenn ein Gast einen Porzess ausführt, der nur einen Core benötigt, aber ihm 4 vCPUs zugewiesen sind, fängt er erst an wenn alle 4 Threads bereit stehen. Das führt dazu, dass eine VM mit vielen vCPUs prinzipell länger braucht um aktiv zu werden bzw. mehr Ressourcen aktiv auf dem Host blokiert, auch wenn diese selbst nicht gebraucht werden. In dem Fall wäre es effizienter der VM weniger vCPUs zu geben, damit sie öfter zum Zug kommt und dabei weniger Gesamtressourcen blokiert. Dazu kommt, dass bei mehr vCPUs mehr Kontextswiche druchgeführt werden müssen um mehr Threads bereit zu stellen, die dann nicht für andere Aufgaben genutzt werden können.
 
Was du irgendwie zuviel anhand von dem was du machst, findest. Ist das innerhalb der 2 Zeilen so richtig?

Genau.

Tun sie das? Cores für die VM fest zugewiesen meinst du? Sollte doch eigentlich nicht möglich sein, dass sich "eine Anwendung eine Core schnappt", da steh ich etwas auf der Leitung.

Ich vermute, wenn eine Anwendung im Gast auf einem Thread Vollgas gibt – ob nun gewünscht oder nicht – dass die auf dem Host mehr oder minder auch auf einem Kern bleibt, sofern genügend Kerne vorhanden sind. Das wird bei mir der Fall sein, denke ich.

Vielleicht verstehe ich dein Vorhaben nicht so ganz. Du hast heute 16 Kerne und diese sind kumuliert bei ~50% Last, aber das alleine sagt ja wenig aus. Denn die 50% können zusammenkommen durch eine gleichmäßige Auslastung aller Kerne zu 50% ihrer Leistung oder eben (was offenbar eher deinen Fall beschreibt) weil acht Kerne Vollgas geben und die anderen sich langweilen.

Wird wohl von beidem etwas sein.

Er hat die Vermutung bzw. das Gefühl bzw. die Beobachtung gemacht, dasss sich die "oberen 50% schneller verbrauchen" "als die unteren 50%", wenn ich das richtig verstehe. Und die Frage ist eben, warum das so sein könnte.

Genau ja.

Dann werfe ich mal eine Vermutung in den Ring: Im niedrigen Lastbereich taktet eine CPU niedriger und hat daher mehr Luft nach oben als wenn der Turbo schon anliegt und dann ausgefahren wird.

Die wird einfach durchgängig mit 3.1 GHz Allcore laufen, denk ich. Die neue CPU soll dann 3.0 machen. Man kann da halt auch nicht stur nach "CPU X macht soviel Benchmark Punkte, CPU Y macht soviel". Darum würde wohl der 12 Kern Ryzen nicht besonders gut da stehen, weil der eine einzelne Anwendung halt einfach um X schneller machen würde, was gar nicht gewünscht ist. Die soll halt laufen, und nimmt sich SC, was sie kriegen kann.

Das heißt, jeder Kern bzw. Thread kann nur einen Prozess bzw. eine VM gleichzeitig bedienen. Soll er was anderes machen, muss er den Kontext wechseln, was Zeit kostet in der keine Leistung, aber Arbeit verrichtet wird. Viele Kontextswitche bedeuten, dass die CPU mehr Zeit mit sich selbst beschäftigt ist.

Wie gesagt, vermute in meinem Setting sind noch genügend Ressourcen frei, damit die Last Threads mehr oder minder verbleiben können wo sie sind.

So sieht die Last im "idle" aus:


Screenshot 2025-09-12 131205.jpg


Mit weniger Kernen konnte man noch die einzelnen Cores und deren Auslastung anzeigen. Das geht mit der 16 Core nicht mehr.

Welche Überwachungsmethode nutzt du eigentlich um die Auslastung auch per Kern aufzuzeichnen?
Netdata?

Gar nichts. Ich sehe die Gesamtauslastung am Host, und im Gast im Taskmanager, dass dort ein Kern halt voll am Anschlag ist.

Screenshot 2025-09-12 133245.jpg


Andere Methode statt neuer CPU wär noch eine GPU gewesen, die SR-IOV kann, und die den Gästen mit den Gameclients zuweisen. Weil ein schöner Teil der Last wird durch das softwaremässige berechnen von 3D erzeugt.
 
Zuletzt bearbeitet:
Du musst vor allem mit dem HT/Hyperthreading-"Kernen" aufpassen.
50% Auslastung der CPU heisst: annähernd alle echten Kerne haben volle Auslastung ! Die anderen sind nur HT-Thread-"Kerne". Ein Hypervisor wird standardmässig normal immer erstmal die echten Kerne belegen.

Und die "HT-Kerne" haben bei weitem nicht die gleiche Leistung wie ein echter Kern; eher so bei 25% dessen bei Intel CPUs diesen Alters. Desto älter die CPU, desto weniger Performance in relation zu einem Thread auf nem echten Kern hat ein Hyperthread.
Sprich: ab 50% Loading wird mit zusätzlicher Last die Last überproportional schnell steigen und dies auch die anderen Threads auf den echten Kernen negativ beeinflussen. Kommt natürlich immer an, was die CPU inhaltlich rechnen muss.
=> Wenn Du 50% Loading hast, hast Du eben nicht nochmal die gleichen 50% zur Verfügung sondern deutlich deutlich weniger. Erzwingst Du nun mehr als die physikalischen Kernzahl gleichzeitig zu nutzen sondern auch die HT-Kerne, erzeugst Du auf den echten Kernen darunter auf hardwareebene nur noch mehr Kontextwechsel weil sich jeder echte Kerne und der dazugehörende "HT-Kern" bestimmte Hardwareressourcen teilen. (manches ist tatsächlich zweimal da, manches nur einmal).
Mit zunehmender Kernauslastung wird der maximale Turboboost runtergezogen; und das wirkt dann natürlich für alle VMs und nicht nur die zusätzlich gestarteten.
siehe hier . (Vergleich: Mein ryzen 9700X läuft singlecore knapp 5.8Ghz, bei allcore Last noch 5.3-5.4; der fällt mir zunehmender Last also etwa 9% ab im Takt. Der 2697 14-15% und bei AVX-Last noch mehr, da gehts schnell Richtung 2.6Ghz Basistakt).

Die Zahl der "HT-Kerne" ist daher eher quasi-irrelevant. Neuere CPUs sind da besser und AMD kommt da aktuell nochmal etwas besser weg als Intel bei HT.

=> damit auf Deine Eingangsfrage: ja, im höheren Lastbereich skaliert Deine CPU schlechter. Deutlich schlechter.


Bzgl. CPU-Performancevergleich kannst Du die reinen Taktraten vergessen, sondern musst auch die IPC (sprich Rechenleistung pro Takt) ansehen. Und da ist eine deralt alte CPU schlicht weit hinten dran.
Sprich das "Bodenaufwischen" stimmt durchaus: der Takt ist nicht hoch und die IPC auch niedrig im verhältnis zu aktuellen CPUs (egal ob Intel oder AMD).
Will sagen: Du kannst mit Deiner Plattform nicht viel mehr ausrichten, wenn Du die Threadzahl skalieren willst.

Btw, aus der CPU-Anzeige im Gast kannst Du nicht schliessen, dass ein bestimmter fixer Host-Kern voll belegt ist solang Du VMs nicht auf bestimmte Kerne festpinst. Ausserdem wird der Gast immer die Basisfrequenz anzeigen und nicht mitbekommen, wenn oder ob da welcher Turbotakt anliegt.

Insofern: der Ryzen würde von der reinen Rechenleistung in den VMs wirklich deutlich besser performen. Viel mehr Takt, viel höhere IPC .
Der alte Intel verteilt seine (kleinere) Rechenleistung beim überbuchen etwas besser, weil die Taktraten bei immer mehr Threads einfach runterskaliert werden. Dafür werden dann aber alle laufenden VMs in der Performance gezogen.
Das ist aber kein Ryzen-Thema, sondern wäre mit ner Intel-Desktop-CPU genauso.

Wenn Du gleichzeitig aber Ram und Lanes brauchst, dann is man in der Tat schnell beim Threadripper oder Epyc.
 
Zuletzt bearbeitet:
Du musst vor allem mit dem HT/Hyperthreading-"Kernen" aufpassen.
50% Auslastung der CPU heisst: annähernd alle echten Kerne haben volle Auslastung ! Die anderen sind nur HT-Thread-"Kerne". Ein Hypervisor wird standardmässig normal immer erstmal die echten Kerne belegen.

Glaube beim ESXi wird die reale Leistung angezeigt. In der vmware WS wird nur der halbe Wert ausgegeben:

Screenshot 2025-09-12 131205.jpg


Screenshot 2025-09-12 135842.jpg



Insofern: nein, der Ryzen würde wirklich deutlich besser performen. Viel mehr Takt, viel höhere IPC .

Der Ryzen würde meine Anwendungen schneller machen. Und von daher auch einfach höher ausgelastet werden. Da hätte ich dann einfach wieder weniger freie Kerne zur Verfügung. Sprich in meinem Anwendungsfall würde da gar nichts besser performen. Die Gameclients würden einfach schneller laufen, was mir total wumpe ist. Für meinen Anwendungsfall stimmt das halt einfach so nicht. Ich habe das jetzt sicher schon zum dritten mal erklärt. Das weiss ich selber, dass ein 9900X mehr Rohleistung bringt. Ich brauche aber viele Kerne. Wenn ich die Plattform wechseln würde, dann wahrscheinlich Sierra Forest mit ausschliesslich Effizienz Kernen.

Ich würde nicht mal geschenkt auf den 12C Ryzen wechseln. Im Desktop ja, aber auf dem Server wär das mehr als kontraproduktiv.
 
Zuletzt bearbeitet:
Dein Ansinnen hab ich schon verstanden; und es geht mir nicht um Ryzen oder Intel.
Im Server liegts nicht an Ryzen oder Intel, sondern wie die CPU ihr thermisches Budget und ihre Gesamtleistung verteilt und ggf. einzelne Kerne dadurch bei höherer Auslastung hardwaremässig begrenzt.
Du hast durch die Frequenzkurve bei höherer Auslastung automatisch, in der CPU verdrahtet, ein Limit.

Bei Desktop-CPUs mit weniger Kernen hast aber deutlich höhere Takte. Und auch mittlerweile halt deutlich mehr IPC als in dem alten 269x v4. Sprich bis zu einem gewissen Grad wird Dein beabsichtiges Limitieren innerhalb der VM auch durch die Kontextwechsel erzeugt, die der Hypervisor dann erzwingt. Ab nen bestimmten Punkt wird das mit den Kontextwechseln dann zuviel natürlich.

Der Hypervisor pinnt eben NICHT einen virtuellen Kern einer VM auf einen physikalischen im Host. Das passiert nur, wenn Du den per Settings in der VM zwingst dazu.
D.h. Du kannst durch in der VM einen Kern voll belastet ausgewiesen bekommen, am Host hat der Hypervisor aber dies auf mehrere Kerne verteilt. Wie er das tut, ist im Code des Hypervisor hinterlegt und natürlich wird er da versuchen, möglichst optimal zu laufen. Desto voller ein Host aber wird, desto schwieriger wird das und erst recht beim Überbuchen, wenn das dann real angefordert wird.
Daher IMMER auch eine VM so knapp wie möglich mit vCPU einstellen; viel hilft da nicht viel sondern führt auch bei Teilllast dann nur zu unnötigen Kontextwechseln und damit Overhead. Diese Rechenzyklen stehen dann anderen VMs nicht mehr zur Verfügung.

Btw, die Angaben auf dem ESXI-Host basieren immer auf den Basistakten. Wenn Du 16 Kerne hast und 2.6Ghz Basistakt, wertet der ESXI diese "Kapazität" von 41.6 Ghz als 100% Anzeige. Wenn der Turbo genutzt wird und die Addition aller Kerne über 41,6 Ghz geht, dann geht es über die 100% .
 
Zuletzt bearbeitet:
Hmm, da bin ich nicht davon überzeugt. Wenn der Host genügend freie Kerne hat, und es drei VMs hat, die sich SC nehmen was sie können, wieso sollte der Host die Tasks dann wild hin und her schubsen? Würde ja Null Sinn machen. Das macht er aber sicher, wenn zu wenig Kerne vorhanden sind. Spielt aber keinen Rugel, die 22 Core CPU ist unterwegs. Bin mir sogar ziemlich sicher, dass die Gesamtauslastung unter den rein rechnerischen Wert von 16 zu 22 sinkt, eben weil da weniger geswitcht werden muss. Obwohl sowohl Allcore als auch Grundtakt deutlich niedriger sind. Gerade auch, wenn ich über die magischen 55% raus komme.

Bin aber kein vmware Threadscheduler Programmierer...
 
Drum hab ich ja geschrieben "Wie er das tut, ist im Code des Hypervisor hinterlegt und natürlich wird er da versuchen, möglichst optimal zu laufen".

Was er da tut oder nicht tut hängt dynamisch von der Last ab; das wird ja pemanent überwacht. Der Ergebnis des Algorithmus kann ja durchaus sein "nächster Zyklus der VM wieder auf dem gleichen Kernen".
Weil natürlich die Entwickler von der Abhängigkeit auch von z.B, im Kern vorhandenen Code im Cache wissen.

Und btw, das braucht natürlich eigene Rechenleistung. Sprich, dem Hypervisor selber muss auch Rechenleistung gelassen werden oder alles auf dem Host wird nochmal träger werden.

Aber: Du kannst Dich eben nicht blind drauf verlassen und sagen "ist immer der gleiche Kern" oder Rückschlüsse von Anzeigen im Guest auf den Host treffen.
Es kann sein, muss es aber nicht. Abhängig von den restlichen Loading-Situationen, abhängig von den Algorithmen des Schedulers.
 
Zuletzt bearbeitet:
Muss dazu sagen, wäre mehr Spielgeld vorhanden, ständen längst ein paar Epyc und TR Maschinen hier. Da ich aber Kettenraucher bin, muss ich mit dem arbeiten, was ich habe. Von daher werden meine LGA 2011-3 Systeme gepimpt bis nichts mehr geht. Und hatte ja im ersten Post schon geschrieben, dass das Rig ja eigentlich soweit macht, was es soll. Ziel war es, am Mainserver bisschen mehr spatzig zu bekommen. Da dürfte ich mit der "neuen" CPU schon mal auf dem richtigen Weg sein.

Und die eigentliche Frage ob die CPUs im oberen Bereich ineffizienter werden, hat ja @Trambahner und einige Andere jetzt beantwortet. Hätte ich mir auch selbst denken können.

Verstehe aber trotzdem nicht, wieso da auf meinen Broadwell-EP rumgeritten werden muss, die ja für meine Spili ausreichend sind offensichtlich. Ich brauch halt keinen neuen Server. Damit hättet Ihr vor einem Jahr kommen sollen. Weil wenn ich ehrlich bin, Boards, Speicher und die ganzen CPUs hatte ich mir vor nicht mal allzulanger Zeit zugelegt. Und bin weiter fleissig am ausbauen und mir auch alles auf Ersatz auf Halde zu legen.

Einziges Problem das ich bei der Hardware sehe, ist dass die je mehr je länger aus dem Softwaresupport raus fällt. So z.B. bei vmware, ESXi 9 wird da sicher nicht mehr drauf laufen wollen.
 
Inkl. Versand für CHF 172.-.

Habe atm eine E5-2697A v4 im Server sowie in der WS. Für eine hatte ich gut 100$ bezahlt, die zweite gab es für CHF 50.-. Die vom Server wandert jetzt in den Backupserver, die E5-2699A v4 in den Mainserver. Die waren bis vor kurzem noch bei über 300.-. Für ein Ersatzmainboard habe ich noch inkl. Versand EUR 76 hin gelegt, 4x 32 GB 2400 RDIMM für EUR 90.-. Und ganz viele Datacenter SSD habe ich dieses Jahr noch zusammen gemischelt.

Aus dem Alter, dass ich Serverhardware neu kaufe, bin ich schon eine Weile raus. Wenn ich denke, was ich für das C612 System 2018 hin geblättert hatte, wird mir ganz schwindelig. Gibt schon Sachen, die kaufe ich neu. Bei PSU spare ich nicht, da habe ich überall mal die guten Seasonic rein gepflanzt. Gehäuse und Backplane habe ich auch neu geholt. Bislang nur gute Erfahrungen gemacht mit gebrauchter Serverhardware.

Ich jammere dann, wenn die ganzen Rechnungen vom Zoll kommen. Aber die Hardware wird einem mittlerweile ja hinterhergeschmissen. Und ist halt solide Plattform.

Somit habe ich zwei komplette X99 Systeme (liebevoll Pilot- und Copilot Seat genannt), eines mit RDIMM, zwei C612 Server mit 256, bzw. 128 GB, und noch Board, 128er Kit und mehrere CPUs auf Ersatz. Auch für die 10 Gbit Firewall habe ich zwei komplette Maschinen und noch ein Board auf Ersatz. Wenn der Blitz einschlägt, kann ich zeitnah wieder starten.

Aber klar, läppert sich trotzdem zusammen. Da wird dauernd dran geschraubt und gepimpt. Aber der Mainserver dürfte jetzt voll ausgebaut sein. Das mit dem dicken Backupserver hat sich halt so ergeben, der gehört dann eher in die Richtung Luxus.

Was sicher Sinn machen würde, wäre die Workstation mal mit einem 9800x3d auszurüsten. Weil FS 2020 läuft da mit 30 fps. Aber leider sitzt die Kohle halt nicht immer so locker. Von daher nicht mehr dieses Jahr.
 
Zuletzt bearbeitet:
Andere Methode statt neuer CPU wär noch eine GPU gewesen, die SR-IOV kann, und die den Gästen mit den Gameclients zuweisen. Weil ein schöner Teil der Last wird durch das softwaremässige berechnen von 3D erzeugt.
Vielleicht die kommende Intel Arc Pro B50/B60 ... die Gerüchte lassen hoffen.
Inkl. Versand für CHF 172.-.
Naja, da hab ich schon mehr Lehrgeld für sinnlosere Versuche bezahlt, ich drück dir die Daumen, dass das hilft.


Allgemein ist die Plattform halt schon alt... die Zeit bleibt halt nicht stehen.
 
Ich kann den Ansatz gut verstehen, die Anforderungen sind halt sehr individuell und in dem Setup steckt viel Arbeit bis alles so läuft wie es soll. Da bleibt man dann bei der bewährten Architektur, und schaut sofern es bezahlbar ist, was man da rauskitzeln kann.

Die Alternative wäre halt wieder mit viel Zeit und Kosten verbunden: neue Hardware, anderer Virtualisierer und dann muss man erstmal wieder lange rumfrickeln bis alles so rund läuft wie bisher.
 
In dem Fall wäre es effizienter der VM weniger vCPUs zu geben, damit sie öfter zum Zug kommt und dabei weniger Gesamtressourcen blokiert.

Das ist mir schon lange bekannt, dass in der Virtualisierung weniger besser als mehr ist. Aber mit dem 16 Kerner wurde ich irgendwann wohl nachlässig. Ich habe jetzt mal den VMs massiv vCPU und vRAM geklaut. Bin gespannt, ob das was an der Auslastung ändert. Ist ja nicht so, dass ich nicht mit mir reden lasse. Hatte da gewissen VMs echt einfach zuviele Ressourcen zugewiesen.
 
Zuletzt bearbeitet:
wenn man sich traut, was aus China zu importieren, da gibt es schöne Supermicro Bretter mit 32 Kern oder mehr Epyc drauf mit jede Menge Ram für wenig geld. Hab mir da mal für knapp 600 EUR ein H11SSL-i mit einem EPYC 7551p und 128 GB Ram gegönnt zum basteln. Läuft tadellos. hat ungefähr 2 Wochen die Lieferung gedauert. Nur einen CPU-Kühler musste ich selbst kaufen. Sind dann zumindest massig Cores und auch PCIe Lanes vorhanden, das man damit auch ein wenig Spaß haben kann... Gut, das H11 Board würde ich heue nicht mehr nehmen, weil es kein PCIe 4.0 unterstützt, aber trotzdem ist das für so ein Projekt dann schon etwas langfristig gesehen gute Leistung
 
Ja, wenn ich Plattform wechseln würde, dann wohl auch SP3. Oder halt wie gesagt Sierra Forest mit ausschliesslich Effizienz Kernen. Aber sind wir ehrlich, soviel Mehrleistung bringen die auch nicht. Ausser dann in den oberen Regionen. Also über meinen angepeilten 22 Core.

Aber sehr geile Basis, hatte dem Kumpel eine Maschine zusammengebaut mit durchgängig PCIe 4.0. Aber das Rig war auch echt teuer zu der Zeit. Er hatte sich den Grossteil neu gekauft. Damals war ich bisschen neidisch auf den Server, welcher wohl leider atm. am verstauben ist.


Musst Dir mal das Brett rein ziehen. Das war damals epyc... Da stimmt dann wirklich alles.

Und sicher importiere ich alles aus China. Hältst Du mich für ein Weichei? Haha, ein Hoch auf die Chinamänner!
 
Zuletzt bearbeitet:
Ich habe jetzt mal den VMs massiv vCPU und vRAM geklaut. Bin gespannt, ob das was an der Auslastung ändert. Ist ja nicht so, dass ich nicht mit mir reden lasse. Hatte da gewissen VMs echt einfach zuviele Ressourcen zugewiesen.
Die Gesamtauslastung bleibt genau gleich. Zumindest was die CPU betrifft. Kann mir aber gut vorstellen, dass jetzt gegen oben mehr Luft ist. Keine Lust jetzt den nested Proxmox anzuwerfen. Hätte ich vor dem optimieren machen sollen, um da wirklich vergleichen zu können.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh