SLES 15 vs. RHEL 9: Vergleich der Leistung von Unternehmensservern

Es gibt keinen allgemeingültigen Leistungssieger zwischen SUSE Linux Enterprise Server 15 und Red Hat Enterprise Linux 9. Eine fundierte Antwort hängt vom jeweiligen Service Pack bzw. der Nebenversion, der Hardware, Kernel-Updates, dem Tuning-Profil, dem Anwendungsstack und der Arbeitslast ab. Der aktuelle Tuning-Leitfaden für SUSE SLES 15 SP7 und die Dokumentation zu Red Hat RHEL 9 beschreiben zwar die Tuning-Möglichkeiten, liefern aber kein kontrolliertes, allgemeines Vergleichsergebnis.

Diese Unterscheidung ist wichtig, da die Dokumentation von SLES 15 SP7 einen Linux-Kernel der Version 6.4 als Basis angibt, während Red Hat RHEL 9 auf Kernel 5.14 basiert und darauf hinweist, dass neuere Änderungen in den Kernel-Stream zurückportiert werden. Diese Versionsbezeichnungen allein lassen keine Rückschlüsse darauf zu, welche Distribution eine Datenbank, einen Webdienst oder eine virtuelle Maschine schneller ausführt. Betrachten Sie sie als Produktfakten und führen Sie anschließend Benchmarks mit der Arbeitslast durch, die Sie tatsächlich ausführen möchten.

Was lässt sich über SLES 15 und RHEL 9 verifizieren?

Bevor Sie die Rechner vergleichen, notieren Sie die genauen installierten Versionen und das aktive Profil auf jedem Rechner. Erfassen Sie beispielsweise die Versionen cat /etc/os-release, uname -rund sudo tuned-adm active. Verwenden Sie die Versionsnummer anstelle der Marketingbezeichnung „SLES 15“ oder „RHEL 9“ als Testbezeichnung.

Ist SLES 15 SP7 dank seiner neueren Kernelbasis schneller als RHEL 9?

Nicht für sich allein. Die Basisversion des Kernels ist kein aussagekräftiger Benchmark. Red Hat pflegt einen stabilen Kernel-Stream mit Hauptversionen und portiert ausgewählte Korrekturen und Funktionen zurück in den Kernel. Daher kann ein RHEL-9-Kernel mit der Versionsnummer 5.14 Funktionen aus neueren Upstream-Releases enthalten. Auch SUSE pflegt und aktualisiert seinen eigenen unterstützten Kernel-Stream. Das Verhalten von Anwendungen hängt von den konkreten Korrekturen, Treibern, der Hardwareunterstützung, der Konfiguration und dem Codepfad der jeweiligen Arbeitslast ab.

Maßnahme: Notieren Sie die vollständige Kernel-Paketversion und den Release-Stand beider Testsysteme. Prüfen Sie bei der Untersuchung einer Funktion oder eines Treibers die Release Notes und die Supportmatrix jedes Herstellers für die jeweilige Version, anstatt nur die ersten beiden Ziffern zu vergleichen uname -r.

Sind die Standardprofile von TuneD gleichwertig?

Es sollte keine Gleichwertigkeit angenommen werden. TuneD ist in beiden Systemen vorhanden, jedoch können sich die installierten Profile, die automatischen Empfehlungen, die Profilinhalte und die lokalen Überschreibungen unterscheiden. Die SUSE-Dokumentation zu SLES 15 SP7 beschreibt Profilempfehlungen basierend auf der Systemkonfiguration. Auch die Red Hat-Dokumentation zu RHEL 9 gibt an, dass die automatische Profilauswahl vom Maschinentyp und den Systemeinstellungen abhängt. Selbst wenn beide Hosts ein Profil mit demselben Namen melden, sollten Sie die Änderungen überprüfen, bevor Sie die Konfigurationen als identisch betrachten.

Aktion: Führen Sie den Befehl sudo tuned-adm activeauf sudo tuned-adm listjedem Host aus. Speichern Sie die Ausgabe und alle benutzerdefinierten Profildateien. Für einen Vergleich der Standardinstallationen behalten Sie die von den jeweiligen Herstellern unterstützten Standardeinstellungen bei und dokumentieren Sie diese. Für einen Vergleich der bestmöglichen Leistung optimieren Sie jedes Betriebssystem separat gemäß den Herstellerangaben und dokumentieren anschließend die verwendeten Profile und Einstellungen.

Wenden Sie nicht alle Leistungsprofile gleichzeitig an. Profile können in Konflikt geraten – beispielsweise kann eine auf Durchsatz optimierte Speichereinstellung durch eine andere Einstellung beeinträchtigt werden, die die Festplattenabschaltung erhöht. Ändern Sie jeweils nur eine relevante Variable, vergewissern Sie sich, dass der Dienst stabil bleibt, und protokollieren Sie die Änderungen.

Welches System eignet sich voraussichtlich besser für Ihre Arbeitslast?

Die Arbeitslast ist in der Regel wichtiger als ein breites Vertriebslabel. Es handelt sich hierbei um Testprioritäten, nicht um Versprechen, welcher Anbieter gewinnen wird:

• CPU-intensive Anwendungen: Verwenden Sie den Produktionscompiler, die Laufzeitumgebung, die Bibliotheken und die Sicherheitseinstellungen. Messen Sie die pro Sekunde erledigte Arbeit und die CPU-Zeit. Ein Mikrobenchmark kann helfen, Unterschiede zu erklären, ersetzt aber keinen Anwendungstest.
• Datenbanken und speicherintensive Dienste: Verwenden Sie eine repräsentative Datenbankversion, ein repräsentatives Schema, eine repräsentative Arbeitsspeichergröße, eine repräsentative Parallelitäts- und Persistenzrichtlinie. Erfassen Sie die Transaktionen pro Sekunde sowie die mittlere und die maximale Latenz; eine höhere durchschnittliche Rate kann langsamere Anfragen verschleiern.
• Speicherintensive Dienste: Behalten Sie dasselbe Laufwerksmodell, dieselbe Controller-Firmware, dasselbe Dateisystem, dieselben Mount-Optionen, denselben Datensatz und dieselbe Warteschlangenlänge bei. Messen Sie das tatsächliche Verhältnis von Lese- und Schreibvorgängen sowie die Latenzverteilung, nicht nur den maximalen sequenziellen Durchsatz.
• Netzwerkdienste: Halten Sie Netzwerkkarte, Firmware, Switch-Pfad, MTU, Offload-Einstellungen und Clientlast konsistent. Messen Sie Anwendungsdurchsatz und Latenz bei der erwarteten Verbindungsanzahl.
• Virtuelle Maschinen oder Container: Vergleichen Sie auf demselben Hypervisor oder Container-Stack mit identischer CPU- und Speicherzuweisung, Host-Richtlinien, Gastprofil und Image. Berücksichtigen Sie Dichte und Ressourcenkonflikte, sofern diese die Produktionsumgebung widerspiegeln.
• Energiesensitive Systeme: Melden Sie den Energieverbrauch pro abgeschlossener Arbeitseinheit, nicht nur die Spitzengeschwindigkeit. Ein System, das weniger Strom verbraucht, aber länger braucht, benötigt möglicherweise nicht insgesamt weniger Energie für einen Stapelverarbeitungsauftrag.

Wenn Sie nicht wissen, wo die Zeit verloren geht, sollten Sie vor der Optimierung die Anwendung profilieren oder CPU-, Speicherauslastung, E/A-Wartezeiten, Netzwerkauslastung und Ausführungswarteschlangen überwachen. Andernfalls behebt ein schnelleres CPU-Profil keinen Speicherengpass.

Wie führt man einen fairen Vergleich durch?

Entscheiden Sie zunächst, welche Frage Sie beantworten möchten. „Welches System ist unmittelbar nach der Installation schneller?“ ist etwas anderes als „Welches System ist nach unterstützter Produktionsoptimierung schneller?“. Vergleichen Sie nicht die optimierte Konfiguration einer Distribution mit den Standardeinstellungen einer anderen und bezeichnen Sie das Ergebnis als Betriebssystemvergleich.

1. Plattformanpassung: Verwenden Sie nach Möglichkeit identische Servermodelle mit gleicher CPU-Stepping-Version, Speicherkapazität, BIOS/Firmware, Speicherkapazität, Netzwerkkarte und Leistungsaufnahme.
2. Softwaredetails einfrieren: SLES-Service-Pack und Update-Level, RHEL-Minor-Release und Update-Level, Kernel-Paket, Anwendungsversion, Laufzeitumgebung/Compiler, Firmware und relevante Sicherheitsvorkehrungen notieren.
3. Steuerungskonfiguration: Protokollieren Sie TuneD-Profile, CPU-Governor bzw. Energiesparmodus, NUMA- und Huge-Page-Einstellungen, Dateisystem- und Mount-Optionen sowie Anwendungsparameter. Belassen Sie die Standardeinstellungen für einen Standardtest oder optimieren Sie beide Systeme gezielt für einen umfassenden Test.
4. Verwenden Sie produktionsnahe Daten und Lasten: Der Test sollte lang genug sein, um ein stabiles Verhalten zu erreichen, und die relevanten Parallelitäts- und Datengrößen berücksichtigen. Definieren Sie den Cache-Status und die Aufwärmprozedur, damit jeder Testlauf vergleichbar startet.
5. Wiederholen und Abweichungen dokumentieren: Testreihenfolge nach Möglichkeit ändern, die Durchläufe wiederholen und den Median sowie die Streuung zwischen den Durchläufen angeben. Durchsatz zusammen mit p95/p99-Latenz, Ressourcenverbrauch und Fehlern, sofern relevant, dokumentieren.
6. Führen Sie eine reproduzierbare Dokumentation: Veröffentlichen Sie die Systemkonfiguration, die Benchmark-Version, die Befehle oder Skripte, die Optimierungsunterschiede und die Rohdaten. Falls es sich um ein Ergebnis eines öffentlichen, standardisierten Benchmarks handelt, befolgen Sie die aktuellen Berichtsregeln dieses Benchmarks.

Die SPEC-CPU-2017-Regeln fordern die vollständige Offenlegung aller leistungsrelevanten Bedingungen und ausreichender Konfigurationsdetails, um ein öffentlich reproduzierbares Ergebnis zu ermöglichen. Dies ist ein sinnvoller Standard, selbst bei Tests mit interner Arbeitslast. Ein Benchmark mit einem einzelnen, unerklärlichen Ergebnis reicht nicht aus, um festzustellen, ob es vom Betriebssystem, Compiler-Flags, BIOS-Einstellungen oder anderer Hardware herrührt.

Was ist bekannt, was hängt von Ihrer Konfiguration ab und was bleibt unbewiesen?

• Bekannt ist, dass die aktuelle Dokumentation zu SLES 15 SP7 und RHEL 9 unterschiedliche Kernel-Streams und TuneD-basierte Leistungskonfigurationen beschreibt. Beide Anbieter dokumentieren Tools für workloadspezifisches Tuning.
• Dies hängt von der Umgebung ab: Durchsatz, Latenz, Stromverbrauch, Startzeit, VM-Dichte, Treiberverhalten und der Aufwand für die kontinuierliche Optimierung. Diese Faktoren variieren je nach Hardware, Anwendung, Release-Stand und Betriebsrichtlinie.
• Aus der überprüften Dokumentation geht nicht hervor, dass SLES 15 grundsätzlich schneller ist als RHEL 9, dass RHEL 9 grundsätzlich schneller ist als SLES 15 oder dass eine bestimmte Kernel-Basisversion für jede Arbeitslast einen Leistungsvorteil garantiert.

Wählen Sie die Distribution, die Ihre Anforderungen an Zertifizierung, Support, Lebenszyklus und Betrieb erfüllt, und validieren Sie die Leistung anschließend mit einem kontrollierten Proof of Concept. Ist die gemessene Differenz geringer als die Schwankung zwischen den einzelnen Testläufen, betrachten Sie die Systeme hinsichtlich dieser Arbeitslast als gleichwertig und entscheiden Sie anhand von Supportfähigkeit, Kompatibilität und Administrationsaufwand.

Offizielle Referenzen

• SUSE: SLES 15 SP7 Systemanalyse- und Optimierungsleitfaden
• SUSE: SLES 15 SP7 Versionshinweise
• Red Hat: Verwaltung, Überwachung und Aktualisierung des RHEL 9-Kernels
• Red Hat: Erste Schritte mit TuneD in RHEL 9
• Red Hat: TuneD-Profile anpassen
• SPEZIFIKATION: CPU 2017 Ausführungs- und Berichtsregeln
• SPEZIFIKATIONEN: CPU-Übersicht 2017 und Fair Use