Betriebssystem-Auswahl und -Optimierung für spezifischen Server-RAM (DDR5-5600MHz)
-
Hallo zusammen,
ich plane einen neuen Build für einen Entwicklungsserver, der primär für das Kompilieren großer C++-Projekte (häufig parallele Builds) und das Testen/Virtualisieren verschiedener Betriebssysteme genutzt werden soll.
Die Hardware-Grundlage steht bereits fest: Ich werde einen PC & Server Memory PC5-44800 8GB-DDR5-5600MHz RDIMM (Registered ECC) Modul verwenden, mit der Option, später auf 64 GB (8x8GB) zu erweitern. Die hohe Bandbreite und die ECC-Funktionalität sind für die Stabilität unter Dauerlast entscheidend.
Meine Frage bezieht sich auf die Betriebssystem-Ebene:
Performance-Optimierung: Welches Betriebssystem (Linux-Distribution, BSD, oder sogar ein speziell konfiguriertes Windows Server) profitiert Ihrer Erfahrung nach am besten von der hohen Taktrate und Bandbreite von DDR5-5600MHz RAM, insbesondere bei speicherintensiven Tasks wie Kompilierung (make -j, ninja) und Virtualisierung (KVM, VirtualBox)?
Gibt es Distributionen, die Scheduling oder Memory Management besonders gut für solche Workloads optimiert haben?
Kernel- und Treiberunterstützung: Benötige ich einen speziell konfigurierten oder sehr neuen Kernel (z.B. 6.x+), um die volle Leistung und Stabilität dieses DDR5-Speichers – insbesondere in Kombination mit einer modernen CPU – ausschöpfen zu können? Oder reicht eine aktuelle LTS-Distribution (wie Ubuntu 22.04 LTS, Debian 12) aus?
C++-Entwicklungsumgebung: Gibt es aus eurer Sicht eine OS-Distribution, die für C++-Entwicklung (Tools, Bibliotheken, Profiler) besonders gut geeignet ist und gleichzeitig die moderne Hardware optimal unterstützt?
Ich bin für jeden Hinweis aus der Praxis dankbar!
Viele Grüße
-
-
Ob es da speziell bezüglich Speicher Unterschiede gibt, kann ich nicht sagen, ich bezweifle das aber. Generell halte ich "Speichertakt und Geschwindigkeit" ohnehin für oft überbewertet. RAM ist generell extrem lahm im Vergleich zur Geschwindigkeit, mit der die CPU arbeitet. Auch die modernen, teuren und "schnellen" Module. Die Geschwindigkeit ist über die Jahre einfach viel zu langsam "mitgewachsen" im Vergleich zur CPU-Verarbeitungsgeschwindgigkeit.
Einen Linux/BSD-Vergleich habe ich nicht, kann dir aber immerhin sagen, dass Windows völlig ungeeignet für so ein System ist: Selbst wenn man Echtzeit-Virenschutz und andere ausbremsenden Features ausschaltet, ist das Erstellen vieler neuer Prozesse spürbar langsamer unter Windows und das Dateisystem kommt nicht gut mit sehr vielen, winzigen Dateien klar. Das kann je nach Build gut und gerne um den Faktor 10 (!) langsamer sein. Auch das "Locking" das Windows bei Dateizugriffen macht, fällt einem bei komplexen, parallelen Builds öfter mal auf die Füße. WSL2 und Build auf einem Linux-Volume der VM hilft da zwar, das ist aber immer noch spürbar langsamer. Ein Linux-Container (z.B. Docker) hilft auch enorm, aber da kann man auch gleich Linux für so einen Server nehmen.
Was die Größe des RAM angeht, kann ich nur "möglichst viel" empfehlen. Bei z.B. einem "make -j16" sollten das "so aus dem Bauch heraus" schon mindestens 32 GiB sein. Für einen ernsthaften "Entwicklungsserver" würde ich da auch eher direkt mit 64GiB anfangen und später auf noch mehr erweitern. Der Grund dafür sind nicht zuletzt Builds mit LTO: Auf meinem Notebook mit 32GiB RAM hier kratzen nämlich Builds mit "make -j16" und "-flto" immer ganz schön dicht am verfügbaren Speicher. Mehr als "-j16" kann ich mir da nicht erlauben. Wenn du in dem Server also ne Server- oder Workstation CPU mit sehr vielen Kernen hast, sollte auch der Speicher entsprechend mitskaliert werden (heisst bei z.B. ner 32-Kern Server-CPU und "make -j64" wären wahrscheinlich eher 128 GiB RAM und mehr angesagt).
-
Das Problem moderner Computer ist weniger die RAM-Geschwindigkeit als die immer größere Latenz. Da AMD momentan deutlich bessere Hardware als Intel liefert, das Folgende nur für AMD erklärt.
Die EPYCs (so auch Threadripper und Threadripper Pro) haben bis zu 16 CCDs. Jedes CCD hängt mit einem GMI am IOD. Die EPYCs lassen sich übers BIOS bzw. auch über Software während der Laufzeit in verschiedenen NUMA-Konfigurationen betreiben. D.h. ein EPYC lässt sich als 1, 2 oder 4 NUMA-Knoten konfigurieren. Grundsätzlich ist es schneller, wenn RAM lokal zum CCD vorgehalten wird, da so direkt darauf zugegriffen werden kann. Man kann unter Linux relativ simpel Prozesse so starten, dass sie nur auf einem NUMA-Knoten laufen und nur auf diesem RAM allozieren.
Was das Scheduling betrifft, man kann grundsätzlich den Kernel anweisen eine andere Scheduling Policy zu fahren. Wenn Du Dir die passende Desktop Erweiterung installierst, geht das bei einer Workstation on-the-fly. Beim Server musst Du einen entsprechende Befehl absetzen.