Ich bin nicht sicher, ob Serverfault der richtige Ort für diese Frage ist, aber ich frage mich, welche Wahl Sie treffen würden, wenn Sie einen neuen CPU-Typ für Ihre Java-Webanwendung auswählen müssten:
a) eine CPU mit 32 Kernen und Taktfrequenz 2,5 Ghz
oder
b) eine CPU mit 8 Kernen, aber einer Taktfrequenz von 3,8 GHz
Da jede eingehende HTTP-Anforderung einer Webanwendung von einem freien Java-Thread bedient wird, kann es sinnvoll sein, sich für a) zu entscheiden, da Sie viermal mehr HTTP-Anforderungen gleichzeitig verarbeiten können. Andererseits kann die CPU b) die Verarbeitung einer einzelnen HTTP-Anforderung jedoch viel schneller abschließen ...
Was denken Sie?
Randnotizen:
- es muss eine physische Maschine sein, VMs oder Cloud-Lösungen sind in diesem Fall keine Option
- RAM ist nicht wichtig, der Server wird am Ende 512GB RAM haben
- Caching: Die Java-Webanwendung verfügt über ein umfangreiches Caching-Framework, die Entscheidung liegt also wirklich bei den CPUs.
Antwort1
kurz und knapp;Die richtige Antwort ist wahrscheinlich „mehr RAM“, aber wie Sie Ihre Frage gestellt haben, lautet die Antwort natürlich: Es kommt darauf an. Andererseits werden 32 Kerne mit 2,5 GHz mit ziemlicher Sicherheit 8 Kerne mit 3,8 GHz schlagen – das sind 4-mal mehr Kerne gegenüber 1,5-mal schnellerer Taktung. Kein sehr fairer Kampf.
Einige Faktoren, die Sie berücksichtigen sollten, sind Transaktionsantwortzeit, gleichzeitige Benutzer und Anwendungsarchitektur.
Transaktionsantwortzeit Wenn Ihre Java-Anwendung die meisten Anfragen in wenigen Millisekunden beantwortet, ist es wahrscheinlich am besten, mehr Kerne zu haben, um mehr gleichzeitige Anfragen verarbeiten zu können. Wenn Ihre Anwendung jedoch hauptsächlich länger andauernde, komplexere Transaktionen verarbeitet, kann sie von schnelleren Kernen profitieren. (Oder auch nicht – siehe unten)
Gleichzeitige Benutzer und Anforderungen Wenn Ihre Java-Anwendung eine große Anzahl gleichzeitiger Anfragen empfängt, sind wahrscheinlich mehr Kerne hilfreich. Wenn Sie nicht so viele gleichzeitige Anfragen haben, zahlen Sie möglicherweise nur für eine Reihe zusätzlicher ungenutzter Kerne.
Anwendungsarchitektur Die von mir erwähnten lang laufenden Anfragen profitieren nicht viel von schnelleren Kernen, wenn der App-Server die meiste Transaktionszeit damit verbringt, auf Antworten von Webdiensten, Datenbanken, Kafaka/MQ/usw. zu warten. Ich habe viele Anwendungen mit 20-30 Sekunden dauernden Transaktionen gesehen, die nur einen kleinen Teil ihrer Antwortzeit mit der Verarbeitung in der Anwendung selbst verbringen und den Rest der Zeit mit dem Warten auf Antworten von Datenbanken und Webdiensten.
Sie müssen auch sicherstellen, dass die verschiedenen Teile Ihrer Anwendung gut zusammenpassen. Es nützt Ihnen nicht viel, wenn 32 oder 64 Threads, die jeweils eine Anfrage bearbeiten, in einer Warteschlange stehen und auf eine von 10 Verbindungen im JDBC-Pool warten (auch bekannt als „Schwein im Python-Problem“). Ein bisschen Planung und Design jetzt erspart Ihnen später viel Arbeit bei der Leistungsbehebung.
Eine letzte Sache – welche CPUs könnten Sie möglicherweise vergleichen? Die billigste 32-Core-CPU mit 2,5 GHz, die ich finden kann, kostet mindestens drei- oder viermal mehr als jede 8-Core-CPU mit 3,8 GHz.
Antwort2
Vorausgesetzt, Ihr Java-Webserver ist entsprechend konfiguriert, sollten Sie sich für mehr Kerne entscheiden.
Es gibt immer noch Abhängigkeiten, wie Semaphoren, gleichzeitige Zugriffe, bei denen immer noch einige Threads warten, unabhängig von der Anzahl der Kerne oder der Geschwindigkeit. Aber es ist besser, wenn es von der CPU (Kernen) verwaltet wird, als vom Betriebssystem (Multithreading).
Und außerdem können 32 Kerne mit 2,5 GHz mehr Threads verarbeiten und sind besser als 8 Kerne mit 3,8 GHz.
Außerdem hängt die von der CPU erzeugte Wärme (unter anderem) von der Frequenz ab und ist nicht linear. Das bedeutet, dass 3,8 GHz mehr Wärme erzeugen als 3,8/2,5 x (muss anhand Ihrer genauen CPU-Typen/-Marken bestätigt werden... viele Websites bieten detaillierte Informationen).
Antwort3
Sie sagen uns, dass die Ausführung einer Anforderung etwa 100 bis 200 ms dauert und dass es sich dabei hauptsächlich um Verarbeitungszeit handelt (obwohl es schwierig ist, die tatsächliche CPU-Ausführung von dem zu unterscheiden, was in Wirklichkeit Speicherzugriff ist), sehr wenig E/A, Wartezeiten für Datenbanken usw.
Sie müssten einen Benchmark durchführen, wie lange es auf jeder der beiden CPUs tatsächlich dauert, aber nehmen wir an, es dauert auf der langsameren CPU (mit 32 Kernen) 150 ms und auf der schnelleren (mit nur 8 Kernen) 100 ms.
Dann könnte die erste CPU bis zu 32/0,15 = 213 Anfragen pro Sekunde verarbeiten.
Die zweite CPU könnte bis zu 8/0,1 = 80 Anfragen pro Sekunde verarbeiten.
Die große Frage ist also: Wie viele Anfragen pro Sekunde erwarten Sie? Wenn Sie nicht annähernd Dutzende Anfragen pro Sekunde benötigen, brauchen Sie die erste CPU nicht, und die zweite bietet Ihnen eine schnellere Ausführungszeit für jede Anfrage. Wenn Sie über 100 Anfragen pro Sekunde benötigen, ist die erste sinnvoll (oder es ist wahrscheinlich sogar sinnvoller, mehr als einen Server zu haben).
Beachten Sie, dass dies sehr grobe Schätzungen sind. Die einzige Möglichkeit, dies sicher herauszufinden, besteht darin, jeden der Server mit einer realen Last zu vergleichen. Wie oben erwähnt, kann es bei schnellen CPUs oder CPUs mit vielen Kernen schnell zu einem Speichermangel kommen. Die Größe der verschiedenen CPU-Caches ist hier sehr wichtig, ebenso wie der „Arbeitssatz“ jeder Anfrage. Und dabei wird wirklich CPU-gebundene Arbeit berücksichtigt, ohne Systemaufrufe, ohne gemeinsam genutzte Ressourcen, ohne E/A …
Antwort4
Vorbemerkung
Ich möchte unterstützen@Möglicherweise nützlich, wahrscheinlich nicht'Sauf jeden Fall brauchbare Antwort.
tldr; Die richtige Antwort ist wahrscheinlich „mehr RAM“
Besonders dieser Punkt.
Vorbehalt
Nicht unbedingt ein Administrator per se.
Eher vielleicht aus der Perspektive der Softwareentwicklung.
Keine Alternative zur Messung
Was wir wissen
Die Maschine ist also
- eine (Enterprise?) Java-basierte Backend-Anwendung ausführen
- öffentlich (jedenfalls in einem größeren Kontext) eine HTTP-API zur Bearbeitung von Client-Anfragen bereitstellen
- vermutlich mit einer Art angehängter Datenbank
- wird ansonsten als nicht sehr I/O-gebunden beschrieben
- ist nicht abhängig von der Verfügbarkeit, Latenz oder dem Durchsatz von Diensten Dritter
Das Bild, das der OP zeichnet, ist gar nicht so vage. Aber gleichzeitig sind die Daten bei weitem nicht ausreichend, um eine Antwort zu geben.in Bezug auf die individuelle Situation des OP.
Sicher, 32 Kerne bei 2/3 der Taktfrequenz sindwahrscheinlichum eine bessere Leistung zu erzielen als 1/4 der Kerne bei vergleichsweise geringem Geschwindigkeitsvorteil. Sicher, die erzeugte Wärme skaliert nicht gut mit Taktraten über der 4-GHz-Schwelle. Und klar, wenn ich blind alle Eier in einen Korb legen müsste, würde ich jederzeit die 32 Kerne wählen.
Was wir nicht wissen
Immer noch viel zu viel.
Jedoch,Über diese einfachen Wahrheiten hinaus wäre ich sehr skeptisch gegenüber einem hypothetischen Versuch einer konkreteren und objektiveren Antwort. Iffes ist zumindest möglich (und Sie haben genügend Gründe, weiterhin davon überzeugt zu sein, dass die Anzahl der Operationen pro Zeiteinheit ein berechtigtes Anliegen ist), die Hardware zu beschaffen, auf der Sie das System ausführen möchten,Messen und testen Sie es, End-to-End.
Eininformierte Entscheidungbeinhaltet relevanteUndglaubwürdige Daten.
OP schrieb: RAM ist nicht wichtig
In den allermeisten Fällen das GedächtnisIstder Engpass.
Zugegeben, das OPfragt vor allem nachCPU-Kerne im Vergleich zur Taktfrequenzund somit scheint die Erinnerung am Rande des Off-Topic zu stehen.
Ich glaube allerdings nicht, dass das so ist. Mir scheint, dass die Frage viel wahrscheinlicher auf einer falschen Prämisse basiert. Verstehen Sie mich nicht falsch, @OP, Ihre Frage ist themenbezogen, gut formuliert und Ihre Besorgnis offensichtlich berechtigt. Ich bin einfach nicht davon überzeugt, dass die Antwort auf die Frage, welche CPU in Ihrem Anwendungsfall „besser“ abschneiden würde, überhaupt (für Sie) relevant ist.
Warum der Arbeitsspeicher (für die CPU) wichtig ist
Der Hauptspeicher istquälend langsam.
Historisch betrachtet neigen wir dazu, RAM im Vergleich zur Festplatte als „den schnellen Speichertyp“ zu betrachten. Im Kontext dieses Vergleichs trifft dies immer noch zu. Im Laufe der letzten Jahrzehnte sind die Prozessorgeschwindigkeiten jedoch durchweg deutlich schneller gewachsen als die Leistung von DRAM. Diese Entwicklung hat im Laufe der Zeit zu dem geführt, was allgemein als"Prozessor-Speicher-Lücke".
Die Lücke zwischen Prozessor- und Speichergeschwindigkeit (Quelle: Carlos Carvalho, Departamento de Informática, Universidade do Minho)
Abrufen einer Cachezeilevom Hauptspeicher in ein CPU-Register dauert etwa 100 Taktzyklender Zeit. Während dieser Zeit meldet Ihr Betriebssystem einen der beiden Hardware-Threads in einem der 4 (?) Kerne Ihrer x86-Architektur alsbeschäftigt.
Soweit dasVerfügbarkeitWas diesen Hardware-Thread betrifft, lügt Ihr Betriebssystem nicht, esist damit beschäftigt zu warten. Die Verarbeitungseinheit selbst ist jedoch, ohne Rücksicht auf die auf sie zukriechende Cache-Zeile,de facto untätig.
Während dieser Zeit wurden keine Anweisungen/Operationen/Berechnungen ausgeführt.
+----------+---------------+---------------------------------------------------------------------------------------------------+
| Type of | size of | Latency due to fetching a cache line |
| mem / op | cache +--------+--------+------------+--------------------------------------------------------------------+
| | (register) | clock | real | normalized | now I feel it |
| | | cycles | time | | |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
| tick | 16KB | 1 | 0.25ns | 1s | Dinner is already served. Sit down, enjoy. |
| | *the* 64 Bits | | | | |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
| L1 | 64KB | 4 | 1ns | 4s | Preparations are done, food's cooking. |
| | | | | | Want a cold one to bridge the gap? |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
| L2 | 2048KB | 11 | ~3ns | 12s | Would you be so kind as to help me dice the broccoli? |
| | | | | | If you want a beer, you will have to go to the corner store. |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
| L3 | 8192KB | 39 | ~10ns | 40s | The car is in the shop, you'll have to get groceries by bike. |
| | | | | | Also, food ain't gonna cook itself, buddy. |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
| DRAM | ~20GB | 107 | ~30ns | 2min | First year of college. First day of the holiday weekend. |
| | | | | | Snow storm. The roommate's are with their families. |
| | | | | | You have a piece of toast, two cigarettes and 3 days ahead of you. |
+----------+---------------+--------+--------+------------+--------------------------------------------------------------------+
Latenzwerte der
Core-i7-9XXSerienchips (Quelle: Scott Meyers, 2010)
Endeffekt Wenn eine korrekte Messung nicht möglich ist, sollten Sie nicht über Kerne und Taktfrequenz diskutieren, sondernDie sicherste Investition für überschüssiges Hardwarebudget ist die Größe des CPU-Cache.
Wenn also der Speicher regelmäßig dafür sorgt, dass einzelne Hardware-Threads im Leerlauf bleiben, sind dann nicht mehr ~Cow Bell~-Kerne die Lösung?
Theoretisch könnte Multi-/Hyperthreading möglich sein, wenn die Software bereit dazu wäre.könntesei schnell
Angenommen, Sie sehen sich beispielsweise Ihre Steuererklärungen der letzten Jahre an, also insgesamt 8 Jahre. Sie halten 12 Monatswerte (Spalten) pro Jahr (Zeile) bereit.
Ein Byte kann nun 256 einzelne Werte enthalten (da seine 8 einzelnen Binärziffern jeweils 2 Zustände annehmen können, was zu 8^2 = 256Permutationen unterschiedlicher Zustände führt). Unabhängig von der Währung scheint 256 etwas zu niedrig, um die Obergrenze von Gehaltszahlen darstellen zu können. Nehmen wir der Argumentation halber außerdem an, dass der kleinste Nennwert („Cent“) keine Rolle spielt (jeder verdient ganze ganzzahlige Werte des Hauptnennwerts). Nehmen wir schließlich an, der Arbeitgeber ist sich der Gehaltslücke zwischen dem oberen Management und der regulären Belegschaft bewusst und führt diese ausgewählten wenigen Mitarbeiter daher in einem völlig anderen Abrechnungssystem.
Nehmen wir also in diesem vereinfachten Szenario an, dass die doppelte Menge an Speicherplatz, also 2 Byte (oder ein „Halbwort“), in der unsignedForm verwendet, also den Bereich von darstellt [0, 2^16 = 65536), ausreicht, um alle monatlichen Gehaltswerte der Mitarbeiter auszudrücken.
In der Sprache/RDBS/Betriebssystem Ihrer Wahl halten Sie jetzt also eine Matrix (eine zweidimensionale Datenstruktur, eine „Liste von Listen“) mit Werten einheitlicher Datengröße (2 Byte/16 Bit).
In C++ wäre das beispielsweise ein . Ich vermute, Sie würden auch in Java ein of of std::vector<std::vector<uint16_t>>verwenden .vectorvectorshort
Hier ist diePreisfrage:
Angenommen, Sie möchten die Werte für diese 8 Jahre an die Inflation anpassen (oder aus einem anderen beliebigen Grund, um in den Adressraum zu schreiben). Wir betrachten eine gleichmäßige Verteilung von 16-Bit-Werten. Sie müssen jeden Wert in der Matrix einmal aufrufen, lesen, ändern und dann in den Adressraum schreiben.
Ist es wichtig, wie Sie die Daten durchsuchen?
Die Antwort ist:ja, sehr sogar. Wenn Sie zuerst über die Zeilen iterieren (die innere Datenstruktur), erhalten Sie in einer Umgebung mit gleichzeitiger Ausführung nahezu perfekte Skalierbarkeit. Hier führt ein zusätzlicher Thread und damit die Hälfte der Daten in einem und die andere Hälfte im anderen Thread Ihren Job doppelt so schnell aus. 4 Threads? 4-fache Leistungssteigerung.
Wenn Sie sich jedoch dafür entscheiden, zuerst die Spalten zu bearbeiten, zwei Threads führen Ihre Aufgabe ausdeutlich langsamer. Sie benötigen etwa 10 parallele Ausführungsthreads, um den negativen Effekt, den die Wahl der Hauptdurchlaufrichtung gerade hatte, abzumildern (!). Und solange Ihr Code in einem einzigen Ausführungsthread lief, konnten Sie keinen Unterschied messen.
+------+------+------+------+------+------+------+
| Year | Jan | Feb | Mar | Apr | ... | Dec |
+------+------+------+------+------+------+------+
| 2019 | 8500 | 9000 | 9000 | 9000 | 9000 | 9000 | <--- contiguous in memory
+------+------+------+------+------+------+------+
| 2018 | 8500 | 8500 | 8500 | 8500 | 8500 | 8500 | <--- 12 * 16Bit (2Byte)
+------+------+------+------+------+------+------+
| 2017 | 8500 | 8500 | 8500 | 8500 | 8500 | 8500 | <--- 3 * (4 * 16Bit = 64Bit (8Byte)
+------+------+------+------+------+------+------+
| ... | 8500 | 7500 | 7500 | 7500 | 7500 | 7500 | <--- 3 cache lines
+------+------+------+------+------+------+------+
| 2011 | 7500 | 7200 | 7200 | 7200 | 7200 | 7200 | <--- 3 lines, likely from the same
+------+------+------+------+------+------+------+ virtual memory page, described by
the same page block.
Der OP schrieb: a) eine CPU mit 32 Kernen und einer Taktfrequenz von 2,5 GHz
oder
b) eine CPU mit 8 Kernen, aber einer Taktfrequenz von 3,8 GHz
Alles andere ist gleich:
-->Bedenken Sie, dass Cachegröße, Speichergröße, die spekulativen Vorabruffunktionen der Hardware und die Ausführung von Software, die die Parallelisierung tatsächlich nutzen kann, alles wichtiger sind als die Taktfrequenz.
--> Auch ohne Abhängigkeit von verteilten Systemen Dritter,Stellen Sie sicher, dass Sie unter Produktionsbedingungen wirklich nicht E/A-gebunden sind.Wenn Sie die Hardware im Haus haben müssen und AWS / GCloud / Azure / Heroku / Whatever-XaaS-IsHipNow nicht mit dieser Aufgabe betraut werden können, investieren Sie in SSDs, auf denen Sie Ihre Datenbank installieren. Während SienichtWenn Sie möchten, dass sich die Datenbank auf derselben physischen Maschine befindet wie Ihre Anwendung, achten Sie darauf, dass die Netzwerkdistanz (messen Sie hier auch die Latenz) so kurz wie möglich ist.
--> Die Wahl einer renommierten, geprüften, erstklassigen HTTP-Serverbibliothek auf „Unternehmensebene“, die zweifelsohne für Parallelität ausgelegt ist, reicht allein nicht aus. Stellen Sie sicher, dass alle Drittanbieterbibliotheken, die Sie in Ihren Routen verwenden, dies auch sind. Stellen Sie sicher, dass Ihr interner Code dies ebenfalls ist.
VMs oder Cloud-Lösungen sind in diesem Fall keine Option
Das verstehe ich.
Es gibt verschiedene triftige Gründe.
Es muss seinAphysische Maschine [...]
[...] CPU mit 32 Kernen und Taktfrequenz 2,5 Ghz
Aber das ist nicht so sehr der Fall.
Weder AWS noch Azure haben verteilte Systeme, Mikroclustering oder Lastenausgleich erfunden. Die Einrichtung auf Bare-Metal-Hardware und ohne Ressourcen im MegaCorp-Stil ist mühsamer, aber SiedürfenBetreiben Sie ein verteiltes Netz aus K8-Clustern direkt in Ihrem eigenen Wohnzimmer. Und auch für selbstgehostete Projekte gibt es Tools für wiederkehrende Integritätsprüfungen und automatische Bereitstellung bei Spitzenlast.
OP schrieb: RAM ist nicht wichtig
Hier ist ein ~hypothetisches~ reproduzierbares Szenario: Aktivieren Sie zram als Ihren Swapspace, denn RAM ist billig und nicht wichtig und so. Führen Sie nun eine stetige, speicherintensive Aufgabe aus, die nicht unbedingt zu häufigem Paging führt. Wenn Sie den Punkt einer ernsthaften LRU-Inversion erreicht haben, wird Ihr Lüfter laut und Ihre CPU-Kerne heiß – weil er mit der Speicherverwaltung beschäftigt ist (Müll in den Swap verschieben und wieder herausholen).
OP schrieb: RAM ist nicht wichtig
Falls ich mich nicht klar genug ausgedrückt habe: Ich denke, Sie sollten diese Meinung noch einmal überdenken.
Kurz und knapp?
32 Kerne.
MehrIstbesser.