Ist ein Prozessor mit höherer Clockrate hier sinnvoller oder mit mehr Kernen?
Hallo zusammen,
ich stehe vor der Entscheidung meinen dedicated Root-Server zu upgraden oder nicht. Es laufen mehrere Gamesserver darauf, welche alle (bis auf einen) nur Singlecore unterstützt. Der jetzige Prozessor ist ein Intel Xeon E5-2630v3 mit 2,4 GHz und 8 Kernen. Sobald mehrere Leute aktiv auf den Servern spielen, fängt alles an sich aufzuhängen, da die CPU mit 99% Leistung läuft.
Jetzt habe ich ein Angebot über einen Server vorliegen, der einen Intel i7-6700k mit 4,0 GHz und 4 Kernen hat. Wäre in diesem Fall, da die meisten dieser Gamesserver eben nur Singlecore unterstützen, der i7 zu bevorzugen, da er eine höhere Clockrate hat? Zumal bei dem jetzigen CPU auch immer mindestens 2 Kerne im Leerlauf sind. Achja, der Server ist angemietet.
Ich freue mich auf euere Antworten!
ich stehe vor der Entscheidung meinen dedicated Root-Server zu upgraden oder nicht. Es laufen mehrere Gamesserver darauf, welche alle (bis auf einen) nur Singlecore unterstützt. Der jetzige Prozessor ist ein Intel Xeon E5-2630v3 mit 2,4 GHz und 8 Kernen. Sobald mehrere Leute aktiv auf den Servern spielen, fängt alles an sich aufzuhängen, da die CPU mit 99% Leistung läuft.
Jetzt habe ich ein Angebot über einen Server vorliegen, der einen Intel i7-6700k mit 4,0 GHz und 4 Kernen hat. Wäre in diesem Fall, da die meisten dieser Gamesserver eben nur Singlecore unterstützen, der i7 zu bevorzugen, da er eine höhere Clockrate hat? Zumal bei dem jetzigen CPU auch immer mindestens 2 Kerne im Leerlauf sind. Achja, der Server ist angemietet.
Ich freue mich auf euere Antworten!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 341438
Url: https://administrator.de/contentid/341438
Ausgedruckt am: 26.11.2024 um 08:11 Uhr
21 Kommentare
Neuester Kommentar
Moin,
Das ist ungefähr so, als ob Du fragst, ob Du lieber einen Porsche eine transporter kaufst. Solange Du nur einzelne Päckchen zu transportieren hast und nicht ganze Paketladungen, kannst du mit dem Porsche schneller zustellen als mit dem Transporter, ansonsten bist Du vermutlich mit dem transporter schneller.
Also:
Solange Du nur singlethreaded Anwendungen hast, zählt geschwindigkeit mehr als Zuladung.
happy hot friday!
lks
Das ist ungefähr so, als ob Du fragst, ob Du lieber einen Porsche eine transporter kaufst. Solange Du nur einzelne Päckchen zu transportieren hast und nicht ganze Paketladungen, kannst du mit dem Porsche schneller zustellen als mit dem Transporter, ansonsten bist Du vermutlich mit dem transporter schneller.
Also:
Solange Du nur singlethreaded Anwendungen hast, zählt geschwindigkeit mehr als Zuladung.
happy hot friday!
lks
Moin,
neben mehr GHz besteht natürlich auch die Möglichkeit die einzelnen Single-Threads per CPU(-Core)-Affinity je einem spezifischen Core zu zuordnen. Beschrieben z.B. hier
lg,
Slainte
neben mehr GHz besteht natürlich auch die Möglichkeit die einzelnen Single-Threads per CPU(-Core)-Affinity je einem spezifischen Core zu zuordnen. Beschrieben z.B. hier
lg,
Slainte
Moin auch,
lks hat da nicht Unrecht.
Ich tippe drauf, dass der Ressourcenhunger Deiner Gameserver hier ausschlaggebend ist und das System unter Druck setzt. Dadurch kommen dann dauerhaft hohe CPU- und RAM-Auslastungen zustande.
Du nutzt ein Blech mit nur einem XEON? Dann kannst Du ruhig wechseln, da die beste Eigenschaft dieses Prozessors der Parallelbetrieb mit weiteren XEON-CPUs ist. Wenn Du dies nicht nutzt hast Du Nachteile. Nur wenn Du im Blech mehr als eine XEON-CPU drin hast, bekommst Du breitbandigere Ressourcen bereitgestellt. Ist viel zu verarbeiten (Vgl. Transporteranalogie von lks) ist das besser, ist weniger schnell zu verarbeiten, fährst Du mit dem I7 einen Porsche.
Zurzeit fährst Du einen Transporter mit einem starken 8Kern-Motor, aber nur halbe Ladefläche. Bringt also nichts.
lks hat da nicht Unrecht.
Ich tippe drauf, dass der Ressourcenhunger Deiner Gameserver hier ausschlaggebend ist und das System unter Druck setzt. Dadurch kommen dann dauerhaft hohe CPU- und RAM-Auslastungen zustande.
Du nutzt ein Blech mit nur einem XEON? Dann kannst Du ruhig wechseln, da die beste Eigenschaft dieses Prozessors der Parallelbetrieb mit weiteren XEON-CPUs ist. Wenn Du dies nicht nutzt hast Du Nachteile. Nur wenn Du im Blech mehr als eine XEON-CPU drin hast, bekommst Du breitbandigere Ressourcen bereitgestellt. Ist viel zu verarbeiten (Vgl. Transporteranalogie von lks) ist das besser, ist weniger schnell zu verarbeiten, fährst Du mit dem I7 einen Porsche.
Zurzeit fährst Du einen Transporter mit einem starken 8Kern-Motor, aber nur halbe Ladefläche. Bringt also nichts.
Zitat von @emeriks:
Hi,
ich würde so rechnen:
Je "Singlecore-Gamesserver" einen Core (ohne HT gerechnet). Für diesen einen, welcher mehrer Core unterstützt, entsprechend viele. Dann noch min. einen für den Host selbst.
Also in die Breite skalieren. Lieber mehr Cores statt mehr Taktrate.
E.
Hi,
ich würde so rechnen:
Je "Singlecore-Gamesserver" einen Core (ohne HT gerechnet). Für diesen einen, welcher mehrer Core unterstützt, entsprechend viele. Dann noch min. einen für den Host selbst.
Also in die Breite skalieren. Lieber mehr Cores statt mehr Taktrate.
E.
Hi,
Deine Überlegung ist natürlich auch haltbar.
Soweit ich weiß, sind XEONs (nicht ohne Grund) kaum übertaktbar. Die Intel Core Prozessoren hingegen können wohl ordentlich frisiert werden.
Wenn @HannibalSmith auf seinem XEON mit 8 Kernen tatsächlich Volllast hat, kann doch nur das Ressourcenmanagement in Windows verbosselt sein. Er müsste dann, wie @SlainteMhath vorschlägt tatsächlich, die Zuweisung der Kerne händisch machen.
Da wäre natürlich mal ein Screenshot schön, der zeigt, wie die Kerne unter max. Last genutzt werden.
Meine Gaming-Rig ist ein alter HP xw8600 mit 2 Xeon Quadcores, 16GB RAM und einer fetten Powercolor XRX480 mit 8GB DDR5.
Es dauert zwar manchmal etwas, bis ein Spiel vollends geladen ist, aber dann läuft es super stabil bei ordentlicher FPS-Rate.
Naja, daß man pro singlethreaded-prozess einen Core spendieren sollte, liegt eigentlich nahe. Sonst hat man zum schluß 4 Fahrer, die sich einen Porsche teilen müssen. bei 5 Fahrern, die sich 4 Porsches teilen, könnte man ggf. damit abfinden, daß zumindest eine immer warten muß.
lks
PS. Man könnte natürlich auch einfach einen hochgetakteten i7 mit 8 Cores nehmen.
Zitat von @HannibalSmith:
Könnte man, klar, ist aber bei einem angemieteten Server schwer dem Hoster zu sagen dass er mal "eben die CPU" austauschen soll^^
Könnte man, klar, ist aber bei einem angemieteten Server schwer dem Hoster zu sagen dass er mal "eben die CPU" austauschen soll^^
Theoretisch geht das, aber aus meiner Sicht nicht mit dem von Dir genannten Core-i7-Modell.
Das Modell Intel® Core™ i7-6900K verwendet, wie der von Dir angegebene XEON-Prozessor den Sockel FCLGA2011-3.
Der von Dir erwähnte Core-i7 6700k scheint ein interessantes Stück zu sein, da er im Grundtakt schon 4GHz liefert, aber nur max. 0,2GHz Übertakt dann verträgt. Er nutzt auch nen anderen Sockel (FCLGA1151).
Hallo,
jeder Gameserver sollte dann aber auch eine vCPU und RAM zugewiesen bekommen und dann zählt eben wie viele Gameserver
dort wirklich vorhanden sind! Eventuell ist auch zu wenig RAM installiert und man hat von der Seite her Probleme, kann das sein?
Gruß
Dobby
jeder Gameserver sollte dann aber auch eine vCPU und RAM zugewiesen bekommen und dann zählt eben wie viele Gameserver
dort wirklich vorhanden sind! Eventuell ist auch zu wenig RAM installiert und man hat von der Seite her Probleme, kann das sein?
Der jetzige Prozessor ist ein Intel Xeon E5-2630v3 mit 2,4 GHz und 8 Kernen.
Und wenn man nun 5 Gameserver hat und nur eine 4 Kern CPU ist das doch auch wieder nichts halbes und nichts ganzes, oder?Gruß
Dobby
Zitat von @beidermachtvongreyscull:
Hi,
Deine Überlegung ist natürlich auch haltbar.
Soweit ich weiß, sind XEONs (nicht ohne Grund) kaum übertaktbar. Die Intel Core Prozessoren hingegen können wohl ordentlich frisiert werden.
Wenn @HannibalSmith auf seinem XEON mit 8 Kernen tatsächlich Volllast hat, kann doch nur das Ressourcenmanagement in Windows verbosselt sein. Er müsste dann, wie @SlainteMhath vorschlägt tatsächlich, die Zuweisung der Kerne händisch machen.
Da wäre natürlich mal ein Screenshot schön, der zeigt, wie die Kerne unter max. Last genutzt werden.
Meine Gaming-Rig ist ein alter HP xw8600 mit 2 Xeon Quadcores, 16GB RAM und einer fetten Powercolor XRX480 mit 8GB DDR5.
Es dauert zwar manchmal etwas, bis ein Spiel vollends geladen ist, aber dann läuft es super stabil bei ordentlicher FPS-Rate.
Zitat von @emeriks:
Hi,
ich würde so rechnen:
Je "Singlecore-Gamesserver" einen Core (ohne HT gerechnet). Für diesen einen, welcher mehrer Core unterstützt, entsprechend viele. Dann noch min. einen für den Host selbst.
Also in die Breite skalieren. Lieber mehr Cores statt mehr Taktrate.
E.
Hi,
ich würde so rechnen:
Je "Singlecore-Gamesserver" einen Core (ohne HT gerechnet). Für diesen einen, welcher mehrer Core unterstützt, entsprechend viele. Dann noch min. einen für den Host selbst.
Also in die Breite skalieren. Lieber mehr Cores statt mehr Taktrate.
E.
Hi,
Deine Überlegung ist natürlich auch haltbar.
Soweit ich weiß, sind XEONs (nicht ohne Grund) kaum übertaktbar. Die Intel Core Prozessoren hingegen können wohl ordentlich frisiert werden.
Wenn @HannibalSmith auf seinem XEON mit 8 Kernen tatsächlich Volllast hat, kann doch nur das Ressourcenmanagement in Windows verbosselt sein. Er müsste dann, wie @SlainteMhath vorschlägt tatsächlich, die Zuweisung der Kerne händisch machen.
Da wäre natürlich mal ein Screenshot schön, der zeigt, wie die Kerne unter max. Last genutzt werden.
Meine Gaming-Rig ist ein alter HP xw8600 mit 2 Xeon Quadcores, 16GB RAM und einer fetten Powercolor XRX480 mit 8GB DDR5.
Es dauert zwar manchmal etwas, bis ein Spiel vollends geladen ist, aber dann läuft es super stabil bei ordentlicher FPS-Rate.
Nö - ist die nicht. Was soll das denn bringen? Ok, nehmen wir die 7 Single-Core-Apps und gehen davon aus das ich 8 Core's habe. Dann hast du trotzdem nicht 7 Anwendungen parallel am laufen. Deine CPU macht genau EINE Anwendung zur Zeit. Ist das eine Single-Core (oder eben nicht mehrprozessorfähige) Anwendung dann liegen die anderen und schlafen gemütlich. Und selbst wenn es eine mehrprozessor-Anwendung ist bedeutet das nicht das auch immer alle CPUs genutzt werden oder gar gleich ausgelastet sind. Und das was Zeit kostet (Daten aus dem Speicher in die CPU laden und bei Prozesswechsel auslagern) hast du in jedem Fall - egal ob du nun irgendwas irgendwohin pinnen möchtest. Woher soll denn Programm X wissen ob Programm Y irgendwas verändert wenn es die Daten nicht zurückgeschrieben hat und in seiner CPU gemütlich pennt?
Um bei dem Beispiel mit dem Auto zu bleiben: Wenn du ein Auto mit 8 Sitzen hast, 8 Personen transportieren willst ist es egal auf welchem SITZ eine Person sitzt. Solang die Vorgabe ist das du nur 1 Person zur Zeit im Auto haben kannst wirst du nicht schneller werden nur weil du den Personen den Sitzplatz zuordnest.
@maretz
Dein Einwand ist insofern vollkommen korrekt, dass wir gar nicht wissen, was das für "gameserver" sind. Ob das jetzt bloß irgendwelche Webserver oder "echte" VM's sind. Auch nicht welches OS der Host hat.
Ich hatte einfach hineininterpretiert, dass es sich hierbei um einen Hypervisor mit mehreren VM's handelt. Ich habe wahrscheinlich statt durch meine Glaskugel durch Aschenbecher geschaut ...
Dein Einwand ist insofern vollkommen korrekt, dass wir gar nicht wissen, was das für "gameserver" sind. Ob das jetzt bloß irgendwelche Webserver oder "echte" VM's sind. Auch nicht welches OS der Host hat.
Ich hatte einfach hineininterpretiert, dass es sich hierbei um einen Hypervisor mit mehreren VM's handelt. Ich habe wahrscheinlich statt durch meine Glaskugel durch Aschenbecher geschaut ...
Zitat von @emeriks:
Ich habe wahrscheinlich statt durch meine Glaskugel durch Aschenbecher geschaut ...
Ich habe wahrscheinlich statt durch meine Glaskugel durch Aschenbecher geschaut ...
Der Boden eines Whiskeyglases funktioniert genausogut.
lks
Moin, auch ein Hypervisor arbeitet nicht anders. Hier kannst du dann zwar jeder VM eine CPU zuweisen, aber auch die werden nicht gleichzeitig sondern nacheinander laufen (aus demselben Grund).
Richtig! Das ist bestimmt der Grund, warum man einem Computer mehrere CPU gibt: Damit sie nacheinander laufen können ... Mal im Ernst: Nein! Es ist sogar Best practice, jeder VM "seinen eigenen" Core zuzuweisen, wenn man denn Performance-Probleme infolge hoher CPU-Last hat oder zu erwarten hat. Es kann sogar sein, in solchen Fällen einer VM weniger vCPU's zu geben statt mehr, um CPU-Last-Probleme zu lösen. Nicht selten kommen diese von der Überbelegung, auch wenn die CPU-Last dabei rein mathematisch unter 100% bleiben sollte.
Moin,
sorry, aber nochmal -> auch wenn du einen Hypervisor einsetzt und 200 CPUs hast wird das nicht echt-parallel ablaufen. Dies gibt einfach die Architektur nicht her. Du kannst natürlich mit mehr CPUs schneller rechnen lassen wenn eine Applikation das unterstützt (ob jetzt Programm in Windows oder eine VM unter einem Hypervisor ist egal). Dann kann es sich z.B. lohnen das du CPUs fest zuweisen willst weil du bei HyperThreading dann wirkliche CPUs nutzen kannst (HT hat gemeinsame Einheiten mit der eigentlichen CPU - da kann das dann zu Wartezeiten kommen).
Aber: Nehmen wir mal an du hast 2 VMs wirklich parallel laufen. Jetzt drückst du eine Taste auf der Tastatur (egal welche). Diese löst einen Interrupt aus. Wenn deine Anwendungen parallel laufen (also Hypervisor und div. VMs) - wer soll die Eingabe verarbeiten? Was passiert wenn 2 wirklich parallel arbeitende VMs + der HV gleichzeitig auf die Festplatte schreiben wollen? Oder in den Speicher - grad wenn da noch ausgelagert werden muss?
Alles andere wäre dann schon sehr spezielle Hardware oder Anwendungszwecke, aber sicher kein Gameserver...
sorry, aber nochmal -> auch wenn du einen Hypervisor einsetzt und 200 CPUs hast wird das nicht echt-parallel ablaufen. Dies gibt einfach die Architektur nicht her. Du kannst natürlich mit mehr CPUs schneller rechnen lassen wenn eine Applikation das unterstützt (ob jetzt Programm in Windows oder eine VM unter einem Hypervisor ist egal). Dann kann es sich z.B. lohnen das du CPUs fest zuweisen willst weil du bei HyperThreading dann wirkliche CPUs nutzen kannst (HT hat gemeinsame Einheiten mit der eigentlichen CPU - da kann das dann zu Wartezeiten kommen).
Aber: Nehmen wir mal an du hast 2 VMs wirklich parallel laufen. Jetzt drückst du eine Taste auf der Tastatur (egal welche). Diese löst einen Interrupt aus. Wenn deine Anwendungen parallel laufen (also Hypervisor und div. VMs) - wer soll die Eingabe verarbeiten? Was passiert wenn 2 wirklich parallel arbeitende VMs + der HV gleichzeitig auf die Festplatte schreiben wollen? Oder in den Speicher - grad wenn da noch ausgelagert werden muss?
Alles andere wäre dann schon sehr spezielle Hardware oder Anwendungszwecke, aber sicher kein Gameserver...
Hm ...
HT ist auch ein Punkt den man beachten muss. Wenn man beim Sizing voll auf die HT-"Cores" setzt, dann wird das bei CPU-hungrigen VM's voll nach hinten losgehen. Wir schalten bei uns HT auf einem Hypervisor Hosts entweder ganz ab oder rechnen es beim Sizing nicht mit.
sorry, aber nochmal -> auch wenn du einen Hypervisor einsetzt und 200 CPUs hast wird das nicht echt-parallel ablaufen. Dies gibt einfach die Architektur nicht her. Du kannst natürlich mit mehr CPUs schneller rechnen lassen wenn eine Applikation das unterstützt (ob jetzt Programm in Windows oder eine VM unter einem Hypervisor ist egal).
Das ist fast korrekt. Zumindest von VMware ESX weiß ich, dass ein Core für eine bestimmte Zeitspanne jeweils vollständig einer VM zugewiesen wird. Die Prozesse innerhalb dieser VM laufen dann ausschließlich auf jenen Cores, welche der VM gerade zugewiesen sind. Und wenn zwei VM's zeitgleich auf verschiedenen Cores laufen, dann laufen sie für diese Zeitspanne tatsächlich parallel. Bei Sizing von Hypervisor Hosts kann man das "ausnutzen", wenn man Engpässe bei der CPU vermeiden will.Dann kann es sich z.B. lohnen das du CPUs fest zuweisen willst weil du bei HyperThreading dann wirkliche CPUs nutzen kannst (HT hat gemeinsame Einheiten mit der eigentlichen CPU - da kann das dann zu Wartezeiten kommen).
Ich vermute, hier hast Du Dich verschrieben? Weil sonst widerspricht Du Dich in diesem Satz.HT ist auch ein Punkt den man beachten muss. Wenn man beim Sizing voll auf die HT-"Cores" setzt, dann wird das bei CPU-hungrigen VM's voll nach hinten losgehen. Wir schalten bei uns HT auf einem Hypervisor Hosts entweder ganz ab oder rechnen es beim Sizing nicht mit.
Aber: Nehmen wir mal an du hast 2 VMs wirklich parallel laufen. Jetzt drückst du eine Taste auf der Tastatur (egal welche). Diese löst einen Interrupt aus. Wenn deine Anwendungen parallel laufen (also Hypervisor und div. VMs) - wer soll die Eingabe verarbeiten?
Das Bsp. Tastatur ist jetzt sehr unglücklich gewählt, weil die Console auf einem Hypervisor nicht direkt an die VM weitergereicht wird. Bei ESX sowieso nicht. Bei Hyper-V erfolgt die Weitergabe der Eingaben über die Consolen-Anwendung oder RDP, VNC oder sonstwas. Primär wird die Eingabe also vom Hyper-V-Host verarbeitet.Was passiert wenn 2 wirklich parallel arbeitende VMs + der HV gleichzeitig auf die Festplatte schreiben wollen? Oder in den Speicher - grad wenn da noch ausgelagert werden muss?
Das wird im SMP geregelt.
Apropos Hyperthreading
lks
PS: Multicores wurden erfunden um viele Prozesse paralell abarbeiten zu lassen und nicht damit die Systeme noch schneller warten können. Es ist also ein Gerücht, daß mehrere Anwendungen oder VMs nicht wirklich parallel laufen können.
lks
PS: Multicores wurden erfunden um viele Prozesse paralell abarbeiten zu lassen und nicht damit die Systeme noch schneller warten können. Es ist also ein Gerücht, daß mehrere Anwendungen oder VMs nicht wirklich parallel laufen können.