SLES 15とRHEL 9：エンタープライズサーバーのパフォーマンス比較

SUSE Linux Enterprise Server 15とRed Hat Enterprise Linux 9の間には、パフォーマンス面で普遍的に勝者となるものはありません。どちらが優れているかは、サービスパックやマイナーリリース、ハードウェア、カーネルのアップデート、チューニングプロファイル、アプリケーションスタック、ワークロードなど、様々な要因によって異なります。現在のSUSE SLES 15 SP7のチューニングガイドとRed HatのRHEL 9のドキュメントでは、チューニング機能について説明していますが、制御された汎用的な直接比較による速度結果を示すものではありません。

この違いは重要です。なぜなら、SLES 15 SP7 のドキュメントでは Linux 6.4 カーネルをベースとしているのに対し、Red Hat のドキュメントでは RHEL 9 はカーネル 5.14 をベースとしており、より新しい変更をカーネルストリームにバックポートしていると記載されているからです。これらのバージョンラベルだけでは、どのディストリビューションがデータベース、Web サービス、または仮想マシンをより高速に実行できるかを予測することはできません。これらは製品情報として扱い、実際に運用する予定のワークロードのベンチマークテストを実施してください。

SLES 15とRHEL 9について検証できることは何ですか？

マシンを比較する前に、各マシンにインストールされている正確なバージョンとアクティブなプロファイルを記録してください。たとえば、、、およびを収集しますcat /etc/os-release。uname -rテストsudo tuned-adm activeラベルには、「SLES 15」や「RHEL 9」といったマーケティング名ではなく、バージョン出力を使用してください。

SLES 15 SP7の新しいカーネルベースは、RHEL 9よりも高速化に貢献しているのでしょうか？

それだけでは判断できません。カーネルの基本バージョンはベンチマークスコアではありません。Red Hat は安定したメジャーリリースカーネルストリームを維持し、選択された修正と機能をバックポートしています。そのため、5.14 と報告する RHEL 9 カーネルには、より新しいアップストリームリリースの機能が含まれている可能性があります。SUSE も独自のサポート対象カーネルストリームを維持および更新しています。アプリケーションの動作は、ワークロードが実行する修正、ドライバ、ハードウェアサポート、構成、およびコードパスによって異なります。

アクション:両方のテストシステムについて、カーネルパッケージの完全なバージョンとリリースレベルを記録します。機能やドライバを調査する場合は、最初の 2 つの数値だけを比較するのではなく、各ベンダーのリリース ノートとサポート マトリックスでその正確なリリースを確認してくださいuname -r。

TuneDのデフォルトプロファイルは同等ですか？

同等性を前提とすべきではありません。TuneDは両方のエコシステムに存在しますが、インストールされているプロファイルセット、自動推奨、プロファイルの内容、およびローカルオーバーライドは異なる場合があります。SUSEのSLES 15 SP7ガイドでは、システム構成に基づいたプロファイルの推奨について説明しています。Red HatのRHEL 9ドキュメントにも、自動プロファイル選択はマシンタイプとシステム設定に依存すると記載されています。両方のホストで同じ名前のプロファイルが報告された場合でも、構成を同一とみなす前に、変更内容を確認してください。

手順：sudo tuned-adm active各ホストで実行しますsudo tuned-adm list。出力とカスタムプロファイルファイルを保存します。「デフォルトインストール」の比較の場合は、各ベンダーがサポートするデフォルト設定を保持し、それを文書化します。「達成可能な最高のパフォーマンス」の比較の場合は、ベンダーのガイダンスに従って各オペレーティングシステムを個別に調整し、使用したプロファイルと設定を報告します。

すべてのパフォーマンスプロファイルを一度に適用しないでください。プロファイルは競合する可能性があります。たとえば、スループット重視のストレージ設定は、ディスクのスピンダウンを増加させる別の設定によって損なわれる可能性があります。関連する変数を一度に1つずつ変更し、サービスが安定していることを確認し、ロールバックの記録を保持してください。

あなたの作業負荷に対して、どちらのシステムの方がより優れたパフォーマンスを発揮する可能性が高いでしょうか？

一般的に、広範な流通チャネルのラベルよりも、ワークロードの方が重要です。これらはテストの優先順位であり、どのベンダーが勝つかという約束ではありません。

• CPU負荷の高いアプリケーションの場合：本番環境で使用されるコンパイラ、ランタイム、ライブラリ、およびセキュリティ設定を使用してください。1秒あたりの処理完了数とCPU時間を測定してください。マイクロベンチマークは差異を説明するのに役立ちますが、アプリケーションテストの代わりにはなりません。
• データベースおよびメモリを大量に消費するサービス：代表的なデータベースバージョン、スキーマ、ワーキングセットサイズ、同時実行性、および永続化ポリシーを使用してください。1秒あたりのトランザクション数と中央値および末尾レイテンシを追跡してください。平均レートが高いと、処理速度の遅いリクエストが隠蔽される可能性があります。
• ストレージを多用するサービスの場合：ドライブモデル、コントローラファームウェア、ファイルシステム、マウントオプション、データセット、キュー深度は同一に保つ。ピークシーケンシャルスループットだけでなく、実際の読み書き比率とレイテンシ分布を測定する。
• ネットワークサービス： NIC、ファームウェア、スイッチパス、MTU、オフロード設定、クライアント負荷を一定に保つ。想定される接続数以下でアプリケーションのスループットとレイテンシを測定する。
• 仮想マシンまたはコンテナ：同じハイパーバイザーまたはコンテナスタック上で、同じCPUおよびメモリ割り当て、ホストポリシー、ゲストプロファイル、およびイメージを使用して比較します。本番環境を反映する場合は、密度とリソース競合も考慮に入れてください。
• 電力消費量に敏感なシステム：ピーク速度だけでなく、完了した作業単位あたりのエネルギー消費量を報告してください。処理時間が長くても消費電力が少ないシステムでも、バッチ処理全体のエネルギー消費量は少なくなるとは限りません。

処理時間がどこに集中しているか分からない場合は、チューニングを行う前に、アプリケーションのプロファイリングを行うか、CPU、メモリ負荷、I/O待機時間、ネットワーク飽和度、実行キューを監視してください。そうしないと、CPUプロファイルを高速化してもストレージのボトルネックは解消されません。

公平な比較を行うにはどうすればよいでしょうか？

まず、どの質問に答えるのかを明確にしましょう。「インストール直後のどちらのシステムが速いか？」と「サポートされている運用環境向けチューニング後のどちらのシステムが速いか？」は異なります。あるディストリビューションのチューニング済み構成と別のディストリビューションのデフォルト構成を比較して、その結果をオペレーティングシステムの比較と呼ぶのは避けましょう。

1. プラットフォームを一致させる：可能な限り、同じCPUステッピング、メモリ容量、BIOS/ファームウェア、ストレージ、NIC、および電力制限を備えた同一のサーバーモデルを使用する。
2. ソフトウェアの詳細を確定します。SLESのサービスパックとアップデートレベル、RHELのマイナーリリースとアップデートレベル、カーネルパッケージ、アプリケーションバージョン、ランタイム/コンパイラ、ファームウェア、および関連するセキュリティ対策を記録します。
3. 設定の制御： TuneDプロファイル、CPUガバナーまたは電源モード、NUMAおよび巨大ページ設定、ファイルシステムおよびマウントオプション、アプリケーションパラメータを記録します。初期設定のままテストを行うか、最適化されたテストを行うために両方のシステムを意図的に調整してください。
4. 本番環境に近いデータと負荷を使用し、安定した動作が得られるまでテスト時間を十分に確保するとともに、重要な同時実行数とデータサイズを含めるようにしてください。キャッシュの状態とウォームアップ手順を定義し、各実行が同様の条件で開始されるようにしてください。
5. 繰り返し測定を行い、変動を報告する：可能な場合はテスト順序を交互に変更し、実行を繰り返し、中央値と実行ごとのばらつきを示す。スループットは、関連する場合はp95/p99レイテンシ、リソース消費量、およびエラーとともに報告する。
6. 再現可能な記録を残してください。システム構成、ベンチマークのバージョン、コマンドまたはスクリプト、チューニングの違い、および生の結果を公開してください。結果が公開されている標準化されたベンチマークに関するものである場合は、そのベンチマークの現在の報告規則に従ってください。

SPECのCPU 2017ルールでは、パフォーマンスに関連する条件を完全に開示し、公開結果を再現できるだけの十分な構成詳細を開示することが求められています。これは、社内ワークロードをテストする場合にも有効な基準です。説明のつかない単一のスコアだけを示すベンチマークでは、結果がオペレーティングシステム、コンパイラフラグ、BIOS設定、あるいは異なるハードウェアに起因するものかどうかを判断するには不十分です。

何が分かっているのか、何が設定に依存するのか、そして何がまだ証明されていないのか？

• 既知の情報：現在のSLES 15 SP7およびRHEL 9のドキュメントには、異なるカーネルストリームとTuneDベースのパフォーマンス構成について記載されています。両ベンダーとも、ワークロード固有のチューニングツールに関するドキュメントを提供しています。
• 環境によって異なります。スループット、レイテンシ、消費電力、起動時間、VM密度、ドライバの動作、そしてチューニングの一貫性を維持するために必要な労力などが影響します。これらは、ハードウェア、アプリケーション、リリースレベル、および運用ポリシーによって異なります。
• レビューしたドキュメントでは、 SLES 15 が RHEL 9 より明らかに高速であること、RHEL 9 が SLES 15 より明らかに高速であること、または、あるカーネルベースバージョンがすべてのワークロードでパフォーマンス上の優位性を保証することは証明されていません。

認証、サポート、ライフサイクル、および運用要件を満たすディストリビューションを選択し、制御された概念実証でパフォーマンスを検証します。測定された差が実行ごとの変動よりも小さい場合は、そのワークロードに対してシステムを同等とみなし、サポート性、互換性、および管理上のニーズに基づいて決定します。

公式資料

• SUSE: SLES 15 SP7 システム分析およびチューニングガイド
• SUSE: SLES 15 SP7 リリースノート
• Red Hat: RHEL 9カーネルの管理、監視、および更新
• Red Hat: RHEL 9 で TuneD を使い始める
• Red Hat: TuneDプロファイルのカスタマイズ
• 仕様：CPU 2017 実行および報告ルール
• 仕様：CPU 2017の概要とフェアユース