SLES 15 vs. RHEL 9 : Comparaison des performances des serveurs d’entreprise

Il n'existe pas de système offrant des performances universellement supérieures à celles de SUSE Linux Enterprise Server 15 et de Red Hat Enterprise Linux 9. Une réponse pertinente dépend du Service Pack ou de la version mineure installée, du matériel, des mises à jour du noyau, du profil d'optimisation, de la pile applicative et de la charge de travail. Le guide d'optimisation actuel de SUSE SLES 15 SP7 et la documentation de Red Hat RHEL 9 décrivent les possibilités d'optimisation ; ils n'établissent pas de comparaison directe et objective des performances.

Cette distinction est importante car la documentation de SLES 15 SP7 indique une base de noyau Linux 6.4, tandis que Red Hat documente RHEL 9 comme étant basé sur le noyau 5.14 et précise qu'il intègre les modifications plus récentes dans sa branche noyau. Ces indications de version, à elles seules, ne permettent pas de prédire quelle distribution exécutera une base de données, un service web ou une machine virtuelle plus rapidement. Considérez-les comme des caractéristiques techniques, puis effectuez des tests de performance sur la charge de travail que vous prévoyez d'utiliser.

Que peut-on vérifier concernant SLES 15 et RHEL 9 ?

Avant de comparer les machines, notez les versions installées et le profil actif sur chacune d'elles. Par exemple, collectez les informations suivantes : cat /etc/os-release` uname -r< sudo tuned-adm activeversion_installée>`, `<version_installée>` et `<profil_actif>`. Utilisez la version affichée plutôt que le nom commercial « SLES 15 » ou « RHEL 9 » comme étiquette de test.

Le noyau plus récent de SLES 15 SP7 le rend-il plus rapide que RHEL 9 ?

Pas à elle seule. La version du noyau n'est pas un indicateur de performance. Red Hat maintient une version majeure stable du noyau et intègre des correctifs et des fonctionnalités sélectionnés ; par conséquent, un noyau RHEL 9 affichant la version 5.14 peut contenir des fonctionnalités issues de versions plus récentes. SUSE maintient et met également à jour sa propre version du noyau. Le comportement des applications dépend des correctifs, des pilotes, du matériel pris en charge, de la configuration et du chemin d'exécution exacts.

Action : consignez la version complète du noyau et son niveau de publication pour les deux systèmes de test. Lors de l’étude d’une fonctionnalité ou d’un pilote, consultez les notes de version et la matrice de compatibilité de chaque fournisseur pour la version exacte concernée, au lieu de comparer uniquement les deux premiers chiffres uname -r.

Les profils TuneD par défaut sont-ils équivalents ?

Aucune équivalence ne doit être présumée. TuneD est présent dans les deux écosystèmes, mais l'ensemble de profils installés, les recommandations automatiques, le contenu des profils et les paramètres locaux peuvent différer. Le guide SUSE SLES 15 SP7 décrit les recommandations de profils en fonction de la configuration système. La documentation Red Hat RHEL 9 indique également que la sélection automatique des profils dépend du type de machine et des paramètres système. Même si les deux hôtes signalent un profil portant le même nom, vérifiez les modifications apportées avant de considérer les configurations comme identiques.

Action : exécuter sudo tuned-adm activela commande sudo tuned-adm listsur chaque hôte. Enregistrer la sortie et les fichiers de profil personnalisés. Pour une comparaison avec une installation par défaut, conserver la configuration par défaut prise en charge par chaque fournisseur et la documenter. Pour une comparaison des meilleures performances possibles, optimiser chaque système d’exploitation séparément en suivant les recommandations du fournisseur, puis indiquer les profils et paramètres utilisés.

N’appliquez pas tous les profils de performance simultanément. Des conflits peuvent survenir entre eux : par exemple, un paramètre de stockage axé sur le débit peut être contrebalancé par un autre paramètre augmentant la mise en veille des disques. Modifiez une seule variable pertinente à la fois, vérifiez la stabilité du service et conservez un historique des modifications apportées.

Quel système est le plus susceptible d'être performant pour votre charge de travail ?

La charge de travail importe généralement plus qu'une simple étiquette de distribution. Il s'agit de priorités de test, et non de promesses quant au fournisseur qui remportera le concours.

• Applications gourmandes en ressources processeur : utilisez le compilateur, l’environnement d’exécution, les bibliothèques et les paramètres de sécurité de production. Mesurez le travail effectué par seconde et le temps processeur. Un microbenchmark peut aider à expliquer une différence, mais ne remplace pas un test d’application.
• Bases de données et services gourmands en mémoire : utilisez une version de base de données, un schéma, une taille d’ensemble de travail, une gestion de la concurrence et une politique de persistance représentatifs. Suivez le nombre de transactions par seconde ainsi que la latence médiane et la latence de queue ; un taux moyen élevé peut masquer des requêtes plus lentes.
• Pour les services gourmands en stockage : conservez le même modèle de disque, le même microprogramme de contrôleur, le même système de fichiers, les mêmes options de montage, le même ensemble de données et la même profondeur de file d’attente. Mesurez la répartition réelle des opérations de lecture/écriture et la latence, et non pas seulement le débit séquentiel maximal.
• Services réseau : assurez la cohérence de la carte réseau, du micrologiciel, du chemin de commutation, de l’unité de transmission maximale (MTU), des paramètres de déchargement et de la charge client. Mesurez le débit et la latence des applications en fonction du nombre de connexions attendu.
• Machines virtuelles ou conteneurs : comparer sur le même hyperviseur ou la même pile de conteneurs, avec la même allocation de processeur et de mémoire, les mêmes stratégies d’hôte, le même profil invité et la même image. Inclure la densité et la contention des ressources si elles reflètent l’environnement de production.
• Systèmes sensibles à la consommation d'énergie : ils indiquent l'énergie consommée par unité de travail effectuée, et non seulement la vitesse de pointe. Un système qui consomme moins d'énergie mais dont le temps d'exécution est plus long peut ne pas consommer moins d'énergie au total pour un traitement par lots.

Si vous ignorez comment le temps est utilisé, effectuez un profilage de l'application ou surveillez l'utilisation du processeur, la pression sur la mémoire, les temps d'attente d'E/S, la saturation du réseau et les files d'attente d'exécution avant toute optimisation. Autrement, un profilage plus rapide du processeur ne résoudra pas un goulot d'étranglement au niveau du stockage.

Comment réaliser une comparaison équitable ?

Commencez par déterminer la question à laquelle vous répondez. « Quel système est le plus rapide immédiatement après l'installation ? » est différent de « Quel système est le plus rapide après une optimisation en production ? ». Ne comparez pas la configuration optimisée d'une distribution avec les paramètres par défaut d'une autre et ne concluez pas à une comparaison de systèmes d'exploitation.

1. Utilisez une plateforme identique : dans la mesure du possible, utilisez des modèles de serveurs identiques, avec la même révision du processeur, la même quantité de mémoire, le même BIOS/micrologiciel, le même stockage, la même carte réseau et les mêmes limites de puissance.
2. Figez les détails du logiciel : notez le pack de services et le niveau de mise à jour de SLES, la version mineure et le niveau de mise à jour de RHEL, le package du noyau, la version de l’application, l’environnement d’exécution/le compilateur, le firmware et les mesures d’atténuation de sécurité pertinentes.
3. Configuration des contrôles : enregistrez les profils TuneD, le mode de gestion de l’alimentation ou le gouverneur du processeur, les paramètres NUMA et de pages énormes, les options de système de fichiers et de montage, ainsi que les paramètres de l’application. Conservez les valeurs par défaut pour un test rapide ou optimisez les deux systèmes pour un test plus poussé.
4. Utilisez des données et une charge similaires à celles de la production : faites en sorte que le test soit suffisamment long pour atteindre un comportement stable et incluez la concurrence et la taille des données pertinentes. Définissez l’état du cache et la procédure d’initialisation afin que chaque exécution démarre de manière comparable.
5. Répétez les tests et indiquez les variations : alternez l’ordre des tests lorsque cela est possible, répétez les exécutions et présentez la médiane ainsi que la dispersion entre les exécutions. Indiquez le débit ainsi que la latence p95/p99, la consommation de ressources et les erreurs, le cas échéant.
6. Conservez un enregistrement reproductible : publiez la configuration système, la version du benchmark, les commandes ou scripts, les différences de réglage et les résultats bruts. S’il s’agit d’un résultat provenant d’un benchmark standardisé public, respectez les règles de rapport en vigueur pour ce benchmark.

Les règles du test CPU 2017 de SPEC exigent la divulgation complète des conditions ayant influencé les performances, ainsi que des détails de configuration suffisants pour reproduire un résultat public. Cette norme est utile même lors de tests internes. Un benchmark avec un seul score non expliqué ne permet pas de déterminer si ce résultat provient du système d'exploitation, des options du compilateur, des paramètres du BIOS ou d'un matériel différent.

Qu’est-ce qui est connu, qu’est-ce qui dépend de votre configuration et qu’est-ce qui reste à prouver ?

• À noter : la documentation actuelle de SLES 15 SP7 et RHEL 9 décrit différents flux de noyau et une configuration de performances basée sur TuneD. Les deux fournisseurs proposent des outils d’optimisation spécifiques aux charges de travail.
• Cela dépend de l'environnement : débit, latence, consommation d'énergie, temps de démarrage, densité de machines virtuelles, comportement des pilotes et efforts nécessaires pour maintenir une optimisation cohérente. Ces paramètres varient selon le matériel, l'application, la version et la politique d'exploitation.
• La documentation examinée n'établit pas : que SLES 15 est catégoriquement plus rapide que RHEL 9, que RHEL 9 est catégoriquement plus rapide que SLES 15, ou qu'une version de noyau de base garantit un avantage de performance pour chaque charge de travail.

Choisissez la distribution qui répond à vos exigences en matière de certification, de support, de cycle de vie et d'exploitation, puis validez ses performances par une preuve de concept contrôlée. Si l'écart mesuré est inférieur à la variation d'une exécution à l'autre, considérez les systèmes comme équivalents pour cette charge de travail et basez votre décision sur les besoins de support, de compatibilité et d'administration.

Références officielles

• SUSE : Guide d’analyse et de réglage du système SLES 15 SP7
• SUSE : Notes de version de SLES 15 SP7
• Red Hat : Gestion, surveillance et mise à jour du noyau RHEL 9
• Red Hat : Premiers pas avec TuneD dans RHEL 9
• Red Hat : Personnalisation des profils TuneD
• SPÉCIFICATIONS : Règles d'exécution et de rapport du processeur 2017
• SPÉCIFICATIONS : Aperçu et utilisation équitable de l'unité centrale de traitement (CPU) 2017