SLES 15 vs. RHEL 9: Confronto delle prestazioni dei server aziendali

Non esiste un vincitore assoluto in termini di prestazioni tra SUSE Linux Enterprise Server 15 e Red Hat Enterprise Linux 9. Una risposta attendibile dipende dall'esatto service pack o versione secondaria, dall'hardware, dagli aggiornamenti del kernel, dal profilo di ottimizzazione, dallo stack applicativo e dal carico di lavoro. La guida all'ottimizzazione di SUSE SLES 15 SP7 e la documentazione di Red Hat per RHEL 9 descrivono le capacità di ottimizzazione, ma non forniscono un risultato di velocità comparativo valido per un utilizzo generale.

Questa distinzione è importante perché la documentazione di SLES 15 SP7 identifica una base kernel Linux 6.4, mentre Red Hat documenta RHEL 9 come basato sul kernel 5.14 e specifica di aver integrato le modifiche più recenti nel proprio kernel. Queste sole etichette di versione non sono sufficienti a prevedere quale distribuzione eseguirà più velocemente un database, un servizio web o una macchina virtuale. Consideratele come dati di prodotto, quindi eseguite dei benchmark con il carico di lavoro che intendete effettivamente utilizzare.

Cosa si può verificare riguardo a SLES 15 e RHEL 9?

Prima di confrontare le macchine, registra le versioni esatte installate e il profilo attivo su ciascuna. Ad esempio, raccogli cat /etc/os-release, uname -r, e sudo tuned-adm active. Utilizza l'output della versione anziché il nome commerciale "SLES 15" o "RHEL 9" come etichetta di test.

Il kernel più recente di SLES 15 SP7 lo rende più veloce di RHEL 9?

Non di per sé. Le versioni base del kernel non sono un punteggio di riferimento. Red Hat mantiene un flusso di kernel stabile per le release principali e applica backport a correzioni e funzionalità selezionate; pertanto, un kernel RHEL 9 che riporta la versione 5.14 può contenere funzionalità provenienti da release upstream più recenti. Anche SUSE mantiene e aggiorna il proprio flusso di kernel supportato. Il comportamento delle applicazioni dipende dalle correzioni specifiche, dai driver, dal supporto hardware, dalla configurazione e dal percorso del codice utilizzato dal carico di lavoro.

Azione: registrare la versione completa del pacchetto del kernel e il livello di rilascio per entrambi i sistemi di test. Quando si esamina una funzionalità o un driver, controllare le note di rilascio e la matrice di supporto di ciascun fornitore per quella specifica versione invece di confrontare solo i primi due numeri da uname -r.

I profili TuneD predefiniti sono equivalenti?

Non si deve presumere alcuna equivalenza. TuneD è presente in entrambi gli ecosistemi, ma il set di profili installati, la raccomandazione automatica, il contenuto del profilo e le sovrascritture locali possono differire. La guida di SUSE SLES 15 SP7 descrive le raccomandazioni del profilo in base alla configurazione del sistema. Anche la documentazione di Red Hat RHEL 9 afferma che la selezione automatica del profilo dipende dal tipo di macchina e dalle impostazioni di sistema. Anche quando entrambi gli host segnalano un profilo con lo stesso nome, è necessario verificare le modifiche apportate prima di considerare le configurazioni identiche.

Azione: eseguire sudo tuned-adm activesu sudo tuned-adm listciascun host. Salvare l'output e gli eventuali file di profilo personalizzati. Per un confronto con "installazione predefinita", conservare l'impostazione predefinita supportata da ciascun fornitore e documentarla. Per un confronto con "prestazioni ottimali", ottimizzare ciascun sistema operativo separatamente seguendo le indicazioni del fornitore, quindi riportare i profili e le impostazioni utilizzati.

Non applicare tutti i profili di prestazioni contemporaneamente. I profili possono entrare in conflitto: ad esempio, un'impostazione di archiviazione orientata alla velocità di trasmissione può essere compromessa da un'altra impostazione che aumenta la velocità di spegnimento dei dischi. Modifica una variabile rilevante alla volta, verifica che il servizio rimanga stabile e conserva una registrazione delle modifiche.

Quale sistema è più adatto al tuo carico di lavoro?

Il carico di lavoro è solitamente più importante di un'etichetta di distribuzione generica. Queste sono priorità di test, non promesse su quale fornitore vincerà:

• Applicazioni con elevato utilizzo della CPU: utilizzare il compilatore, il runtime, le librerie e le impostazioni di sicurezza di produzione. Misurare il lavoro completato al secondo e il tempo CPU. Un microbenchmark può aiutare a spiegare una differenza, ma non può sostituire un test dell'applicazione.
• Database e servizi che richiedono un elevato utilizzo di memoria: utilizzare una versione del database, uno schema, una dimensione del working set, una politica di concorrenza e una politica di persistenza rappresentative. Monitorare le transazioni al secondo insieme alla latenza media e ai valori estremi; una velocità media più elevata può nascondere richieste più lente.
• Servizi ad alta intensità di archiviazione: mantieni lo stesso modello di unità, firmware del controller, file system, opzioni di montaggio, set di dati e profondità della coda. Misura il mix effettivo di lettura/scrittura e la distribuzione della latenza, non solo il throughput sequenziale di picco.
• Servizi di rete: mantenere coerenti la scheda di rete, il firmware, il percorso dello switch, l'MTU, le impostazioni di offload e il carico dei client. Misurare la velocità di trasmissione e la latenza dell'applicazione in base al numero di connessioni previsto.
• Macchine virtuali o container: confrontare sullo stesso hypervisor o stack di container, con la stessa allocazione di CPU e memoria, le stesse policy dell'host, il profilo guest e l'immagine. Includere la densità e la contesa delle risorse se rispecchiano l'ambiente di produzione.
• Sistemi sensibili al consumo energetico: segnalare l'energia consumata per unità di lavoro completata, non solo la velocità massima. Un sistema che consuma meno energia impiegando più tempo potrebbe non consumare meno energia totale per un lavoro in batch.

Se non sai dove va a finire il tempo, esegui un'analisi del profilo dell'applicazione o monitora la CPU, la pressione della memoria, i tempi di attesa I/O, la saturazione della rete e le code di esecuzione prima di ottimizzare. Altrimenti, un profilo CPU più veloce non risolverà un collo di bottiglia dello storage.

Come si effettua un confronto equo?

Innanzitutto, decidi a quale domanda stai rispondendo. "Quale sistema è più veloce subito dopo l'installazione?" è diverso da "Quale sistema è più veloce dopo l'ottimizzazione in ambiente di produzione?". Non confrontare la configurazione ottimizzata di una distribuzione con le impostazioni predefinite di un'altra e non definire il risultato un confronto tra sistemi operativi.

1. Abbina la piattaforma: utilizza, ove possibile, modelli di server identici, con la stessa architettura della CPU, la stessa quantità di memoria, lo stesso BIOS/firmware, lo stesso storage, la stessa scheda di rete e gli stessi limiti di alimentazione.
2. Blocca i dettagli del software: prendi nota del service pack e del livello di aggiornamento di SLES, della versione secondaria e del livello di aggiornamento di RHEL, del pacchetto del kernel, della versione dell'applicazione, del runtime/compilatore, del firmware e delle relative misure di sicurezza.
3. Controllo della configurazione: registrazione dei profili TuneD, governor della CPU o modalità di alimentazione, impostazioni NUMA e huge-page, opzioni del filesystem e di mount e parametri dell'applicazione. Mantieni le impostazioni predefinite per un test immediato oppure ottimizza entrambi i sistemi intenzionalmente per un test più preciso.
4. Utilizza dati e carichi simili a quelli di produzione: esegui il test per una durata sufficiente a raggiungere un comportamento stabile e includi la concorrenza e la dimensione dei dati rilevanti. Definisci lo stato della cache e la procedura di riscaldamento in modo che ogni esecuzione inizi in modo comparabile.
5. Ripeti e segnala le variazioni: alterna l'ordine dei test quando possibile, ripeti le esecuzioni e mostra la mediana più la dispersione tra le esecuzioni. Segnala il throughput insieme alla latenza p95/p99, al consumo di risorse e agli errori, ove pertinenti.
6. Conservare una documentazione riproducibile: pubblicare la configurazione del sistema, la versione del benchmark, i comandi o gli script, le differenze di ottimizzazione e i risultati grezzi. Se un risultato si riferisce a un benchmark standardizzato pubblico, seguire le regole di reporting vigenti per tale benchmark.

Le regole SPEC CPU 2017 richiedono la completa divulgazione delle condizioni rilevanti per le prestazioni e sufficienti dettagli di configurazione per riprodurre un risultato pubblico. Questo è uno standard utile anche quando si testa un carico di lavoro interno. Un benchmark con un singolo punteggio non spiegato non è sufficiente per stabilire se il risultato dipenda dal sistema operativo, dai flag del compilatore, dalle impostazioni del BIOS o da hardware diverso.

Cosa è noto, cosa dipende dalla configurazione e cosa resta da dimostrare?

• Informazioni note: la documentazione attuale di SLES 15 SP7 e RHEL 9 descrive diversi flussi del kernel e la configurazione delle prestazioni basata su TuneD. Entrambi i fornitori documentano strumenti per l'ottimizzazione specifica del carico di lavoro.
• Dipende dall'ambiente: throughput, latenza, consumo energetico, tempo di avvio, densità delle macchine virtuali, comportamento dei driver e impegno richiesto per mantenere una configurazione coerente. Questi fattori variano in base all'hardware, all'applicazione, al livello di rilascio e alle politiche operative.
• La documentazione esaminata non ha dimostrato che SLES 15 sia categoricamente più veloce di RHEL 9, che RHEL 9 sia categoricamente più veloce di SLES 15 o che una versione base del kernel garantisca un vantaggio prestazionale per ogni carico di lavoro.

Scegli la distribuzione che soddisfa i requisiti di certificazione, supporto, ciclo di vita e operativi, quindi convalida le prestazioni con una prova di concetto controllata. Se la differenza misurata è inferiore alla variazione tra un'esecuzione e l'altra, considera i sistemi come equivalenti per quel carico di lavoro e prendi la decisione in base alle esigenze di supporto, compatibilità e amministrazione.

Riferimenti ufficiali

• SUSE: Guida all'analisi e all'ottimizzazione del sistema SLES 15 SP7
• Note di rilascio di SUSE: SLES 15 SP7
• Red Hat: Gestione, monitoraggio e aggiornamento del kernel RHEL 9
• Red Hat: Guida introduttiva a TuneD in RHEL 9
• Red Hat: Personalizzazione dei profili TuneD
• SPECIFICHE: Regole di esecuzione e reporting della CPU 2017
• SPECIFICHE: Panoramica e utilizzo corretto della CPU 2017