第1章 Red Hat Enterprise Linux for Real Time システムのチューニングを開始する前に


Red Hat Enterprise Linux for Real Time は、非常に高い決定論要件を持つアプリケーション向けに、適切にチューニングされたシステムでの使用を目的としています。カーネルシステムのチューニングにより、決定論の改善が大きくなります。たとえば、多くのワークロードでシステム全体のチューニングにより、約 90 % 程度で結果の一貫性が向上します。これは、Red Hat Enterprise Linux for Real Time を使用する前に、お客様が最初に標準の Red Hat Enterprise Linux の 2章一般的なシステムチューニング を実行することが推奨されます。

Red Hat Enterprise Linux for Real Time カーネルの調整を行うに当たり重要なこと

  1. お待ちください。
    リアルタイムチューニングは反復的なプロセスで、いくつかの変数を微調整することはあまりできず、変更が最適であることに気がつくことはありません。システムに最適なチューニングセットを絞り込むためには、数日または数週間かかると思ってください。
    また、常に長いテストを実行します。あるチューニングパラメーターを変更してから 5 分間のテストを実行しても、チューニングのセットを適切に検証したとは言えません。テストの長さを調整可能にし、数分以上実行してください。テストが数時間実行した複数の異なるチューニングセットに絞り込みを試み、一度に数時間または数日間これらのセットを実行して、最大レイテンシーまたはリソース消費の隅をキャッチします。
  2. 正確にお願いします。
    アプリケーションに測定メカニズムを構築し、特定のチューニング変更がどのようにアプリケーションのパフォーマンスに与える影響を正確に測定できるようにします。マウスの方がスムーズに移動するという内容は正しくないことがほとんどで、人によって異なります。ハード測定を行い、後で分析するためにそれらを記録します。
  3. 順序だった手順を心がける
    テストの実行間で変数のチューニングに複数の変更を加えがちです。ただし、これを実行することは、テスト結果に影響を及ぼすチューニングを絞り込むことができないことを意味します。テスト間のチューニング変更は、可能な限り小さく実行されるようにします。
  4. 保守的に
    また、チューニング時に大きな変更を行うことを希望していますが、ほとんどの場合、増分変更を行う方が適切です。優先度の値が最小値から最大値に達すると、長期的に考えて結果がよくなることがわかります。
  5. 賢く
    利用可能なツールを使用します。Tuna グラフィカルチューニングツールを使用すると、スレッドと割り込み、スレッドの優先度、アプリケーションが使用するプロセッサーを分離できるプロセッサーを簡単に変更できます。taskset および chrt コマンドラインユーティリティーを使用すると、Tuna が実行するほとんどのことを実行できます。パフォーマンスの問題が発生した場合は、ftrace および perf ツールを使用してレイテンシーの問題を特定できます。
  6. 柔軟性に
    アプリケーションで値をハードコーディングするのではなく、外部ツールを使用してポリシー、優先度、アフィニティーを変更します。これにより、さまざまな組み合わせを試し、論理を簡素化できます。適切な結果を提供する設定が見つかったら、アプリケーションをアプリケーションに追加したり、アプリケーションの起動時に設定を実装する起動ロジックを設定できます。

スケジューリングポリシー

Linux では、以下の 3 つの主要なスケジューリングポリシーが使用されます。

SCHED_OTHER (SCHED_NORMAL とも呼ばれます)
これはデフォルトのスレッドポリシーで、カーネルが制御する動的な優先度を持ちます。優先度はスレッドアクティビティーに基づいて変更されます。このポリシーを持つスレッドは、リアルタイム優先度が 0 と見なされます。
SCHED_FIFO (先入れ先出し)
優先度の範囲が 1 - 99 までのリアルタイムポリシー。ここでは、1 が最も低く、99 が最も高くなります。SCHED_FIFO スレッドは常に SCHED_OTHER スレッドよりも優先度が高くなります (たとえば、優先度が 1SCHED_FIFO スレッドは、任意SCHED_OTHER スレッドよりも優先度が高くなります)。SCHED_FIFO スレッドとして作成されたスレッドの優先度はどれも固定され、優先度の高いスレッドによってブロックまたはプリエンプションされるまで実行されます。
SCHED_RR (ラウンドロビン)
SCHED_RR は、SCHED_FIFO を変更したものです。同じ優先度のスレッドにはクォンタムがあり、同じ優先度のすべての SCHED_RR スレッド間でラウンドロビン方式でスケジュールされます。このポリシーはほとんど使用されません。

1.1. レイテンシーテストの実行および結果を解釈

潜在的なハードウェアプラットフォームがリアルタイム操作に適していることを確認するには、リアルタイムカーネルでレイテンシーテストおよびパフォーマンステストを実行する必要があります。このテストは、負荷がかかった可能性のある BIOS またはシステムのチューニング (パーティションを含む) の問題を強調表示することができます。

1.1.1. 主なステップ

手順1.1 システムをテストし、結果を解釈するには、以下を行います。

  1. 低レイテンシー操作に必要なチューニング手順については、ベンダーのドキュメントを参照してください。
    この手順は、システムを System Management Mode (SMM) に変換する System Management Interrupts を減らしたり、削除したりします。システムが SMM を使用している場合は、ファームウェアが実行されており、オペレーティングシステムコードを実行していません。つまり、SMM 内で期限切れになるタイマーは、システムが通常の動作に移行するまで待機する必要があります。これにより、SMI が Linux によってブロックされず、実際に SMI を実行したことがベンダー固有のパフォーマンスカウンターレジスターで確認されるため、説明できないレイテンシーが発生する可能性があります。
    警告
    致命的なハードウェア障害が発生する可能性があるため、Red Hat は SMI を完全に無効にしないことを強く推奨します。
  2. RHEL-RT および rt-tests パッケージがインストールされていることを確認します。
    この手順では、システムを適切に調整したことを確認します。
  3. hwlatdetect プログラムを実行します。
    hwlatdetect は、クロックソースをポーリングして説明できないギャップを探すことで、ハードウェア/ファームウェアによって発生する遅延を検出します。
    通常、プログラムはハードウェアアーキテクチャーまたは BIOS/EFI ファームウェアによって導入される遅延を探すため、hwlatdetect の実行中にシステムに何らかの負荷をかける必要はありません。
    hwlatdetect の典型的な出力は次のようになります。
    # hwlatdetect --duration=60s
    hwlatdetect:  test duration 60 seconds
    	detector: tracer
    	parameters:
    		Latency threshold: 10us
    		Sample window:     1000000us
    		Sample width:      500000us
    		Non-sampling period:  500000us
    		Output File:       None
    
    Starting test
    test finished
    Max Latency: Below threshold
    Samples recorded: 0
    Samples exceeding threshold: 0
    上記の結果は、ファームウェアからのシステム中断を最小限に抑えるために調整されたシステムです。
    ただし、以下に示すように、システム中断を最小限に抑えるためにすべてのシステムを調整することはできません。
    # hwlatdetect --duration=10s
    hwlatdetect:  test duration 10 seconds
    	detector: tracer
    	parameters:
    		Latency threshold: 10us
    		Sample window:     1000000us
    		Sample width:      500000us
    		Non-sampling period:  500000us
    		Output File:       None
    
    Starting test
    test finished
    Max Latency: 18us
    Samples recorded: 10
    Samples exceeding threshold: 10
    SMIs during run: 0
    ts: 1519674281.220664736, inner:17, outer:15
    ts: 1519674282.721666674, inner:18, outer:17
    ts: 1519674283.722667966, inner:16, outer:17
    ts: 1519674284.723669259, inner:17, outer:18
    ts: 1519674285.724670551, inner:16, outer:17
    ts: 1519674286.725671843, inner:17, outer:17
    ts: 1519674287.726673136, inner:17, outer:16
    ts: 1519674288.727674428, inner:16, outer:18
    ts: 1519674289.728675721, inner:17, outer:17
    ts: 1519674290.729677013, inner:18, outer:17
    上記の結果は、システム クロックソース の連続読み取り中に、15 - 18 us の範囲で 10 回の遅延が発生したことを示しています。
    hwlatdetect は、原因不明の遅延を検出するために ディテクター として トレーサー メカニズムを使用していました。以前のバージョンでは、ftrace トレーサー ではなくカーネルモジュールが使用されていました。
    パラメーター は、遅延と検出の実行方法を報告します。デフォルトのレイテンシーしきい値は 10 マイクロ秒 (10 ミリ秒) で、サンプルウィンドウは 1 秒で、サンプリングウィンドウは 0.5 秒でした。
    その結果、トレーサー は指定された期間の各秒の半分の間実行される ディテクター スレッドを実行しました。
    ディテクター スレッドは、次の疑似コードを実行するループを実行します。
    t1 = timestamp()
    	loop:
    		t0 = timestamp()
    		if (t0 - t1) > threshold
    		   outer = (t0 - t1)
    		t1 = timestamp
    		if (t1 - t0) > threshold
    		   inner = (t1 - t0)
    		if inner or outer:
    		   print
    		if t1 > duration:
    		   goto out
    		goto loop
    	out:
    内部ループの比較では、t0 - t1 が指定されたしきい値 (デフォルトは 10 マイクロ秒) を超えないことがチェックされます。外側のループの比較では、ループの下部と上部の間の時間 t1 - t0 をチェックします。タイムスタンプレジスタの連続する読み取りの時間は、数十ナノ秒 (通常はレジスター読み取り、比較ジャンプ、条件付きジャンプ) である必要があります。したがって、連続する読み取り間の他の遅延がファームウェアによって導入されるか、システムコンポーネントの接続方法により行われます。
    注記
    hwlatdetector によって 内側外側 に出力される値は、最良の場合の最大遅延です。レイテンシー値は、現在のシステム クロックソース (通常は タイムスタンプカウンター または TSC レジスターですが、HPET または ACPI 電源管理クロックの可能性もあります) の連続読み取り間の差分と、ハードウェアとファームウェアの組み合わせによって導入される連続読み取り間の遅延です。
適切なハードウェアとファームウェアの組み合わせを見つけたら、次のステップは、負荷がかかった状態でシステムのリアルタイムパフォーマンスをテストすることです。

1.1.2. 負荷によるシステムのリアルタイムパフォーマンスのテスト

RHEL-RT は、負荷がかかった状態でシステムのリアルタイムパフォーマンスをテストするための rteval ユーティリティーを提供します。rteval は、SCHED_OTHER タスクの重いシステム負荷を開始し、各オンライン CPU のリアルタイム応答を測定します。ロードは、ループ内の Linux カーネルツリーと Hackbench 合成ベンチマークの並列 作成 です。
その目的は、システムを、それぞれのコアに常にスケジュールするジョブがある状態にすることです。ジョブは、メモリーの割り当て/解放、ディスク I/O、コンピュートタスク、メモリーコピーなどのさまざまなタスクを実行します。
負荷が起動すると、rtevalcyclictest 測定プログラムを開始します。このプログラムは、各オンラインコアで SCHED_FIFO リアルタイムスレッドを開始し、リアルタイムスケジューリング応答時間を測定します。各測定スレッドはタイムスタンプを取得し、ある間隔スリープした後、ウェイクアップ後に再度タイムスタンプを取得します。測定されるレイテンシーは t1 - (t0 + i) です。これは、実際のウェイクアップ時間 t1 と、最初のタイムスタンプ t0 の理論上のウェイクアップ時間にスリープ間隔 i を加えた時間との間の差です。
rteval 実行の詳細は、システムのブートログとともに XML ファイルに書き込まれます。その後、rteval-<date>-N.tar.bz2 ファイルが生成されます。N<date> の N 回目の実行を表すカウンターです。XML ファイルから生成された、以下のようなレポートが画面に出力されます。
System:  
Statistics: 
	Samples:           1440463955
	Mean:              4.40624790712us
	Median:            0.0us
	Mode:              4us
	Range:             54us
	Min:               2us
	Max:               56us
	Mean Absolute Dev: 1.0776661507us
	Std.dev:           1.81821060672us

CPU core 0       Priority: 95
Statistics: 
	Samples:           36011847
	Mean:              5.46434910711us
	Median:            4us
	Mode:              4us
	Range:             38us
	Min:               2us
	Max:               40us
	Mean Absolute Dev: 2.13785341159us
	Std.dev:           3.50155558554us
上記のレポートでは、ハードウェアの詳細、実行の長さ、使用されるオプション、およびタイミング結果 (CPU ごとおよびシステム全体) の詳細が表示されます。レポートを再生成するには、#rteval --summarize rteval-<date>-n.tar.bz2 コマンド。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る