SLES 15 versus RHEL 9: Vergelijking van de serverprestaties in de zakelijke markt

Er is geen universele winnaar qua prestaties tussen SUSE Linux Enterprise Server 15 en Red Hat Enterprise Linux 9. Een gefundeerd antwoord hangt af van het exacte servicepack of de minor release, de hardware, kernelupdates, het tuningprofiel, de applicatiestack en de workload. De huidige tuninghandleiding voor SUSE SLES 15 SP7 en de documentatie van Red Hat RHEL 9 beschrijven tuningmogelijkheden; ze geven geen gecontroleerd, algemeen toepasbaar snelheidsresultaat voor een directe vergelijking.

Dit onderscheid is belangrijk omdat de SLES 15 SP7-documentatie een Linux 6.4-kernel als basis noemt, terwijl Red Hat RHEL 9 documenteert als gebaseerd op kernel 5.14 en aangeeft dat het nieuwere wijzigingen in de kernelstream heeft opgenomen. Deze versieaanduidingen alleen voorspellen niet welke distributie een database, webservice of virtuele machine sneller zal uitvoeren. Beschouw ze als productfeiten en test vervolgens de workload die u daadwerkelijk van plan bent uit te voeren.

Wat kan er geverifieerd worden met betrekking tot SLES 15 en RHEL 9?

Voordat u machines vergelijkt, noteert u de exacte geïnstalleerde versies en het actieve profiel op elke machine. Verzamel bijvoorbeeld cat /etc/os-release, uname -r, en sudo tuned-adm active. Gebruik de versie-output in plaats van de marketingnaam "SLES 15" of "RHEL 9" als uw testlabel.

Is SLES 15 SP7 dankzij de nieuwere kernelbasis sneller dan RHEL 9?

Niet op zichzelf. Kernelbasisversies zijn geen maatstaf. Red Hat onderhoudt een stabiele hoofdrelease-kernelstream en voegt geselecteerde fixes en functies toe aan nieuwere versies; daarom kan een RHEL 9-kernel met versie 5.14 functionaliteit bevatten van nieuwere upstream-releases. SUSE onderhoudt en actualiseert ook zijn eigen ondersteunde kernelstream. Het gedrag van applicaties hangt af van de exacte fixes, drivers, hardwareondersteuning, configuratie en het codepad dat de workload doorloopt.

Actie: noteer de volledige kernelpakketversie en het releaseniveau voor beide testsystemen. Controleer bij het onderzoeken van een functie of driver de release-opmerkingen en de ondersteuningsmatrix van elke leverancier voor die specifieke release, in plaats van alleen de eerste twee cijfers te vergelijken uname -r.

Zijn de standaard TuneD-profielen gelijkwaardig?

Er mag geen gelijkwaardigheid worden aangenomen. TuneD bestaat in beide ecosystemen, maar de geïnstalleerde profielset, automatische aanbevelingen, profielinhoud en lokale overschrijvingen kunnen verschillen. De SUSE SLES 15 SP7-handleiding beschrijft profielaanbevelingen op basis van de systeemconfiguratie. De RHEL 9-documentatie van Red Hat vermeldt ook dat de automatische profielselectie afhankelijk is van het machinetype en de systeeminstellingen. Zelfs wanneer beide hosts een profiel met dezelfde naam rapporteren, controleer dan wat het wijzigt voordat u de configuraties als identiek beschouwt.

Actie: voer de opdracht sudo tuned-adm activeuit sudo tuned-adm listop elke host. Sla de uitvoer en eventuele aangepaste profielbestanden op. Voor een vergelijking met een "standaardinstallatie" dient u de door elke leverancier ondersteunde standaardinstellingen te bewaren en te documenteren. Voor een vergelijking met de "best haalbare prestaties" dient u elk besturingssysteem afzonderlijk af te stemmen volgens de richtlijnen van de leverancier en vervolgens de gebruikte profielen en instellingen te rapporteren.

Pas niet alle prestatieprofielen tegelijk toe. Profielen kunnen conflicteren; zo kan een opslaginstelling die gericht is op doorvoer, worden ondermijnd door een andere instelling die de schijf sneller laat uitvallen. Wijzig één relevante variabele tegelijk, controleer of de service stabiel blijft en houd een overzicht bij van de terugdraaiing.

Welk systeem presteert waarschijnlijk beter bij uw werkzaamheden?

De werklast is meestal belangrijker dan een algemeen distributielabel. Dit zijn testprioriteiten, geen beloftes over welke leverancier zal winnen:

• CPU-intensieve applicaties: gebruik de productiecompiler, runtime, bibliotheken en beveiligingsinstellingen. Meet de voltooide werkzaamheden per seconde en de CPU-tijd. Een microbenchmark kan helpen om een ​​verschil te verklaren, maar kan een applicatietest niet vervangen.
• Databases en geheugenintensieve services: gebruik een representatieve databaseversie, schema, werksetgrootte, gelijktijdigheid en persistentiebeleid. Houd het aantal transacties per seconde bij, samen met de mediaan en de staartlatentie; een hogere gemiddelde snelheid kan tragere verzoeken maskeren.
• Opslagintensieve services: behoud hetzelfde schijfmodel, controllerfirmware, bestandssysteem, mountopties, dataset en wachtrijdiepte. Meet de werkelijke lees-/schrijfverhouding en latentieverdeling, niet alleen de pieksnelheid bij sequentiële bewerkingen.
• Netwerkservices: zorg ervoor dat de netwerkkaart, firmware, switchpad, MTU, offload-instellingen en clientbelasting consistent blijven. Meet de applicatiedoorvoer en -latentie bij het verwachte aantal verbindingen.
• Virtuele machines of containers: vergelijk op basis van dezelfde hypervisor of containerstack, met dezelfde CPU- en geheugentoewijzing, hostbeleid, gastprofiel en image. Neem dichtheid en resourceconflicten mee als dat representatief is voor de productieomgeving.
• Energiegevoelige systemen: rapporteer het energieverbruik per voltooide werkeenheid, niet alleen de pieksnelheid. Een systeem dat minder energie verbruikt maar er langer over doet, verbruikt mogelijk niet per se minder totale energie voor een batchtaak.

Als je niet weet waar de tijd naartoe gaat, profileer dan de applicatie of monitor het CPU-gebruik, de geheugenbelasting, de I/O-wachttijden, de netwerkbelasting en de uitvoeringswachtrijen voordat je gaat optimaliseren. Anders zal een sneller CPU-profiel een opslagknelpunt niet oplossen.

Hoe voer je een eerlijke vergelijking uit?

Bepaal eerst welke vraag je beantwoordt. "Welk systeem is direct na installatie sneller?" is iets anders dan "Welk systeem is sneller na ondersteunde productieoptimalisatie?". Vergelijk de geoptimaliseerde configuratie van de ene distributie niet met de standaardinstellingen van een andere en noem het resultaat vervolgens een vergelijking tussen besturingssystemen.

1. Stem het platform op elkaar af: gebruik waar mogelijk identieke servermodellen met dezelfde CPU-stepping, geheugencapaciteit, BIOS/firmware, opslag, netwerkkaart en stroomlimieten.
2. Leg de softwaregegevens vast: noteer het SLES-servicepack en het updateniveau, de RHEL-minorrelease en het updateniveau, het kernelpakket, de applicatieversie, de runtime/compiler, de firmware en de relevante beveiligingsmaatregelen.
3. Configuratiebeheer: registreer TuneD-profielen, CPU-governor of energiemodus, NUMA- en huge-page-instellingen, bestandssysteem- en mountopties en applicatieparameters. Laat deze op de standaardinstellingen staan ​​voor een test direct na installatie of stem beide systemen doelbewust af voor een geoptimaliseerde test.
4. Gebruik productiedata en -belasting: zorg ervoor dat de test lang genoeg duurt om stabiel gedrag te bereiken en neem de relevante gelijktijdigheid en datagrootte mee. Definieer de cachestatus en de opwarmprocedure zodat elke testrun op een vergelijkbare manier begint.
5. Herhaal en rapporteer variatie: wissel indien mogelijk de testvolgorde af, herhaal de runs en toon de mediaan plus de spreiding tussen de runs. Rapporteer de doorvoer samen met de p95/p99-latentie, het resourceverbruik en de fouten waar relevant.
6. Houd een reproduceerbaar verslag bij: publiceer de systeemconfiguratie, de benchmarkversie, de commando's of scripts, de afstemmingsverschillen en de ruwe resultaten. Als een resultaat afkomstig is van een openbare, gestandaardiseerde benchmark, volg dan de geldende rapportageregels van die benchmark.

De SPEC CPU 2017-regels vereisen volledige openbaarmaking van prestatiegerelateerde omstandigheden en voldoende configuratiegegevens om een ​​publiek resultaat te kunnen reproduceren. Dat is een nuttige standaard, zelfs bij het testen van een interne workload. Een benchmark met slechts één onverklaarde score is niet voldoende om te bepalen of een resultaat afkomstig is van het besturingssysteem, compilerflags, BIOS-instellingen of andere hardware.

Wat is bekend, wat hangt af van je configuratie en wat is nog niet bewezen?

• Bekend: de huidige documentatie van SLES 15 SP7 en RHEL 9 beschrijft verschillende kernelstreams en op TuneD gebaseerde prestatieconfiguratie. Beide leveranciers documenteren tools voor workloadspecifieke tuning.
• Dit hangt af van de omgeving: doorvoer, latentie, stroomverbruik, opstarttijd, VM-dichtheid, drivergedrag en de inspanning die nodig is om de optimalisatie consistent te houden. Deze factoren variëren per hardware, applicatie, releaseversie en operationeel beleid.
• Uit de geraadpleegde documentatie blijkt niet dat SLES 15 aantoonbaar sneller is dan RHEL 9, dat RHEL 9 aantoonbaar sneller is dan SLES 15, of dat één kernelversie een prestatievoordeel garandeert voor elke workload.

Kies de distributie die voldoet aan uw certificerings-, ondersteunings-, levenscyclus- en operationele vereisten en valideer vervolgens de prestaties met een gecontroleerde proof of concept. Als het gemeten verschil kleiner is dan de variatie tussen opeenvolgende uitvoeringen, beschouw de systemen dan als gelijkwaardig voor die specifieke workload en bepaal de beste optie op basis van ondersteunbaarheid, compatibiliteit en beheersbehoeften.

Officiële referenties

• SUSE: SLES 15 SP7 Systeemanalyse- en afstemmingshandleiding
• SUSE: Release-opmerkingen voor SLES 15 SP7
• Red Hat: Het beheren, bewaken en bijwerken van de RHEL 9-kernel
• Red Hat: Aan de slag met TuneD in RHEL 9
• Red Hat: TuneD-profielen aanpassen
• SPECIFICATIES: CPU 2017 Uitvoerings- en rapportageregels
• SPEC: Overzicht van CPU 2017 en Fair Use