SLES 15 vs. RHEL 9: Compararea performanței serverelor Enterprise

Nu există un câștigător universal în materie de performanță între SUSE Linux Enterprise Server 15 și Red Hat Enterprise Linux 9. Un răspuns justificabil depinde de pachetul de service sau de versiunea minoră exactă, de hardware, de actualizările kernelului, de profilul de optimizare, de stiva de aplicații și de volumul de lucru. Ghidul actual de optimizare pentru SUSE SLES 15 SP7 și documentația Red Hat pentru RHEL 9 descriu capacitățile de optimizare; acestea nu stabilesc un rezultat controlat, general, al vitezei comparative.

Această distincție este importantă deoarece documentația SLES 15 SP7 identifică o bază de kernel Linux 6.4, în timp ce Red Hat documentează RHEL 9 ca fiind bazat pe kernelul 5.14 și menționează că acesta include modificările mai noi în fluxul său de kernel. Aceste etichete de versiune în sine nu prevăd ce distribuție va rula o bază de date, un serviciu web sau o mașină virtuală mai rapid. Tratați-le ca informații despre produs, apoi comparați volumul de lucru pe care intenționați să îl operați.

Ce se poate verifica despre SLES 15 și RHEL 9?

Înainte de a compara mașinile, înregistrați versiunile exacte instalate și profilul activ pe fiecare. De exemplu, colectați cat /etc/os-release, uname -rși sudo tuned-adm active. Folosiți rezultatul versiunii în loc de numele de marketing „SLES 15” sau „RHEL 9” ca etichetă de testare.

Noul kernel al SLES 15 SP7 îl face mai rapid decât RHEL 9?

Nu de la sine. Versiunile de bază ale kernelului nu reprezintă un scor de referință. Red Hat menține un flux stabil de kernel pentru versiunile majore și realizează retroporturi ale corecțiilor și caracteristicilor selectate; prin urmare, un kernel RHEL 9 care raportează versiunea 5.14 poate conține funcționalități din versiuni upstream mai noi. SUSE menține și actualizează, de asemenea, propriul flux de kernel suportat. Comportamentul aplicației depinde de corecțiile exacte, driverele, suportul hardware, configurația și calea de cod pe care o exercită sarcina de lucru.

Acțiune: înregistrați versiunea completă a pachetului de kernel și nivelul de lansare pentru ambele sisteme de testare. Când investigați o caracteristică sau un driver, verificați notele de lansare și matricea de suport ale fiecărui furnizor pentru versiunea exactă respectivă, în loc să comparați doar primele două numere din uname -r.

Profilurile TuneD implicite sunt echivalente?

Nu trebuie presupusă nicio echivalență. TuneD există în ambele ecosisteme, dar setul de profiluri instalate, recomandarea automată, conținutul profilului și suprascrierile locale pot diferi. Ghidul SLES 15 SP7 de la SUSE descrie recomandările de profiluri bazate pe configurația sistemului. Documentația RHEL 9 de la Red Hat precizează, de asemenea, că selectarea automată a profilului depinde de tipul mașinii și de setările sistemului. Chiar și atunci când ambele gazde raportează un profil cu același nume, verificați ce modificări aduce acesta înainte de a trata configurațiile ca fiind identice.

Acțiune: rulați sudo tuned-adm activeși sudo tuned-adm listpe fiecare gazdă. Salvați rezultatul și orice fișiere de profil personalizat. Pentru o comparație a „instalării implicite”, păstrați setările implicite acceptate de fiecare furnizor și documentați-le. Pentru o comparație a „celei mai bune performanțe posibile”, reglați fiecare sistem de operare separat folosind instrucțiunile furnizorului, apoi raportați profilurile și setările utilizate.

Nu aplicați fiecare profil de performanță simultan. Profilurile pot intra în conflict - de exemplu, o setare de stocare orientată spre debit poate fi compromisă de o altă setare care crește viteza de rotație a discului. Modificați câte o variabilă relevantă pe rând, confirmați că serviciul rămâne stabil și păstrați o înregistrare a revenirilor la starea inițială.

Ce sistem este probabil să funcționeze mai bine pentru volumul dvs. de lucru?

Volumul de lucru contează de obicei mai mult decât o etichetă de distribuție largă. Acestea sunt priorități de testare, nu promisiuni despre care furnizor va câștiga:

• Aplicații cu funcție CPU: utilizați compilatorul de producție, runtime-ul, bibliotecile și setările de securitate. Măsurați munca finalizată pe secundă și timpul CPU. Un microbenchmark poate ajuta la explicarea unei diferențe, dar nu poate înlocui un test al aplicației.
• Baze de date și servicii care consumă multă memorie: utilizați o versiune reprezentativă a bazei de date, o schemă, o dimensiune a setului de lucru, o politică de concurență și persistență. Urmăriți tranzacțiile pe secundă împreună cu latența mediană și cea finală; o rată medie mai mare poate ascunde solicitări mai lente.
• Servicii care necesită mult spațiu de stocare: păstrați același model de unitate, firmware-ul controlerului, sistemul de fișiere, opțiunile de montare, setul de date și adâncimea cozii. Măsurați mixul real de citire/scriere și distribuția latenței, nu doar debitul secvențial maxim.
• Servicii de rețea: mențineți consecvența plăcii de rețea (NIC), a firmware-ului, a căii de comutare, a MTU-ului, a setărilor de descărcare și a încărcării clientului. Măsurați debitul și latența aplicației sub numărul așteptat de conexiuni.
• Mașini virtuale sau containere: comparați pe același hypervisor sau stivă de containere, cu aceeași alocare de CPU și memorie, politici gazdă, profil de oaspete și imagine. Includeți densitatea și conflictul de resurse dacă acestea reflectă producția.
• Sisteme sensibile la consumul de energie: raportează energia pe unitate de lucru finalizată, nu doar viteza maximă. Un sistem care consumă mai puțină energie, deși durează mai mult, poate să nu utilizeze mai puțină energie totală pentru o lucrare în lot.

Dacă nu știți încotro se duce timpul, profilați aplicația sau monitorizați procesorul, presiunea memoriei, așteptarea I/O, saturația rețelei și rulați cozile înainte de reglare. Altfel, un profil CPU mai rapid nu va remedia blocajul de stocare.

Cum ar trebui să faci o comparație corectă?

Mai întâi, decideți la ce întrebare răspundeți. Întrebarea „Care sistem este mai rapid imediat după instalare?” este diferită de „Care sistem este mai rapid după reglarea de producție acceptată?”. Nu comparați configurația reglată a unei distribuții cu setările implicite ale altei distribuții și nu numiți rezultatul o comparație a sistemului de operare.

1. Potriviți platforma: utilizați modele de server identice acolo unde este posibil, cu aceleași trepte de CPU, ocupare a memoriei, BIOS/firmware, stocare, placă de rețea și limite de putere.
2. Înghețați detaliile software-ului: notați pachetul service pack și nivelul de actualizare SLES, versiunea minoră și nivelul de actualizare RHEL, pachetul kernel, versiunea aplicației, runtime/compilatorul, firmware-ul și atenuările de securitate relevante.
3. Configurarea controlului: înregistrați profilurile TuneD, guvernatorul CPU sau modul de alimentare, setările NUMA și pentru pagini uriașe, opțiunile sistemului de fișiere și de montare și parametrii aplicației. Păstrați-le la valorile implicite pentru un test predefinit sau reglați ambele sisteme intenționat pentru un test optimizat.
4. Folosește date și încărcări similare celor din producție: fă testul suficient de lung pentru a atinge un comportament constant și include concurența și dimensiunea datelor care contează. Definește starea memoriei cache și procedura de încălzire, astfel încât fiecare rulare să înceapă în mod comparabil.
5. Repetați și raportați variația: alternați ordinea testelor atunci când este posibil, repetați rulările și afișați mediana plus dispersia de la o rulare la alta. Raportați debitul împreună cu latența p95/p99, consumul de resurse și erorile, acolo unde este cazul.
6. Păstrați o evidență reproductibilă: publicați configurația sistemului, versiunea benchmark-ului, comenzile sau scripturile, diferențele de reglare și rezultatele brute. Dacă un rezultat este pentru un benchmark standardizat public, urmați regulile de raportare actuale ale benchmark-ului respectiv.

Regulile SPEC CPU 2017 impun dezvăluirea completă a condițiilor relevante pentru performanță și suficiente detalii de configurație pentru a reproduce un rezultat public. Acesta este un standard util chiar și atunci când testați o sarcină de lucru internă. Un test de performanță cu un singur scor inexplicabil nu este suficient pentru a spune dacă un rezultat provine de la sistemul de operare, de la semnalizatoarele compilatorului, de la setările BIOS sau de la hardware diferit.

Ce se știe, ce depinde de configurația ta și ce rămâne nedemonstrat?

• Cunoscut: documentația actuală pentru SLES 15 SP7 și RHEL 9 descrie diferite fluxuri de kernel și configurații de performanță bazate pe TuneD. Ambii furnizori documentează instrumente pentru reglarea specifică sarcinii de lucru.
• Depinde de mediu: debit, latență, consum de energie, timpul de pornire, densitatea mașinilor virtuale, comportamentul driverelor și efortul necesar pentru a menține consecvența optimizării. Acestea variază în funcție de hardware, aplicație, nivel de lansare și politică operațională.
• Documentația analizată nu a stabilit: că SLES 15 este categoric mai rapid decât RHEL 9, că RHEL 9 este categoric mai rapid decât SLES 15 sau că o versiune de bază a kernelului garantează un avantaj de performanță pentru fiecare sarcină de lucru.

Alegeți distribuția care îndeplinește cerințele dvs. de certificare, asistență, ciclu de viață și operaționale, apoi validați performanța cu o demonstrație controlată a conceptului. Dacă diferența măsurată este mai mică decât variația de la o execuție la alta, tratați sistemele ca fiind legate pentru sarcina de lucru respectivă și decideți utilizând nevoile de asistență, compatibilitate și administrare.

Referințe oficiale

• SUSE: Ghid de analiză și optimizare a sistemului SLES 15 SP7
• SUSE: Note de lansare SLES 15 SP7
• Red Hat: Gestionarea, monitorizarea și actualizarea kernelului RHEL 9
• Red Hat: Introducere în TuneD în RHEL 9
• Red Hat: Personalizarea profilurilor TuneD
• SPECIFICAȚII: Reguli de rulare și raportare CPU 2017
• SPECIFICAȚII: Prezentare generală a procesorului 2017 și utilizare loială