コンテンツにスキップ 
私はのレイテンシを測定しています。 Linuxスケジューラ 的を絞って分析を行い、外れ値を解析し、インタラクティブおよびリアルタイムのワークロードが確実に反応するようになるまでパラメータを最適化します。このようにして、スケジューラのレイテンシを体系的に低減し、 カーネルのパフォーマンス 目隠し飛行なし。.
中心点
- 測定方法: perf sched、eBPF runqlat、schedstat、および cyclictest により、全体像を把握できます。.
- 最悪の場合: 異常値がユーザー体験やリアルタイムの締め切りを左右している。.
- CFSパラメータ: sched_latency_ns とタイムスライスが応答時間に影響を与える。.
- ポリシー: SCHED_FIFO/RR/DEADLINE は、重要なスレッドを優先します。.
- 断熱: CPUのピンニングとIRQのチューニングにより、レイテンシが安定する。.
カーネルにおけるスケジューラのレイテンシとは何か
私は、スケジューラのレイテンシを、以下の間の時間として定義する。 目覚め タスクの開始時と、コンテキスト切り替え後にそのコードが実行される瞬間との間。 割り込みによってI/Oの待機状態が終了し、ハンドラがスレッドを実行可能状態としてマークすると、スケジューラが選択を行い、スレッドの切り替えを開始します。対話型システムでは1マイクロ秒単位が重要ですが、日常的にはとりわけ 最悪の場合-レイテンシが体感に与える影響。平均値が良好に見えても、わずか数百ミリ秒の遅延が操作性を台無しにしてしまう。まさにその理由から、私はカーネル内の処理チェーン全体を俯瞰しつつ、ウェイクアップからCPUへの移行までの区間に焦点を当てている。.
なぜ最悪ケースのレイテンシが重要なのか
私は平均値だけを評価するわけではありません。なぜなら、平均値が低い場合でも、 ヒント を隠蔽してしまう可能性がある。まれに発生するピークによってバッファが空になると、音声に雑音が入り、期限が切れると取引のタイミングが狂ってしまう。デスクトップ、サーバー、リアルタイム処理のいずれにおいても、わずかな異常値が全体を左右する。 応答性 何千もの良質なサンプルよりも重要です。そのため、私は分布幅を狭くし、ジッター値を厳密に制御することを目指しています。最大値が低下して初めて、滑らかで予測可能な流れが生まれるのです。.
スケジューラのレイテンシの測定：ツールと手順
私は次のように始める。 パーフェクト また、ワークロードごとにスケジューライベントを記録します。「perf sched record」はデータを収集し、「perf sched latency」はタスクごとにデータを分類し、「perf sched timehist」はタイムスタンプ付きのイベントを表示します。 これにより、「sched-out」から「sched-in」までの待機時間、ウェイクアップから実際の実行までの遅延、および純粋な実行時間を確認できます。詳細なCPU分析を行うには、これを以下のガイドと組み合わせています： CPUのボトルネック対策に最適なperf. この視点により、ボトルネックが可視化され、その原因が競合、優先順位、あるいはオーバーヘッドのいずれであるかが明らかになります。.
eBPF を使って、実行待ち時間を直接 ランキュー. 通常使用する「runqlat」は、ナノ秒単位のヒストグラムを生成するため、典型的なゾーンやまれな急増を識別できます。このような分布は、CPUの分離やポリシーの変更に対して顕著に反応し、チューニングの手順を進めるための確固たる根拠を提供してくれます。 変更の前後で測定を繰り返し、ピークが消失するまで続けます。その時点で初めて、結果を満足のいくものと評価します。.
個々のタスクについては、「/proc//schedstat」を参照し、CPU実行時間の割合を比較して、, ランキュー-待機時間とスリープフェーズ。一定間隔でデータを取得することで、CPU使用率、レイテンシ比率、スリープ比率といった指標が算出されます。これにより、プロセスがCPU時間を争っているのか、それともI/Oボトルネックでブロックされているのかを素早く把握できます。こうした明確な把握があるからこそ、誤った対象への最適化を回避できるのです。 追加のテストとして、cyclictestを高優先度で実行し、ジッタや最大値を記録しています。.
測定値の読み取りと解釈
まず、測定値を定性的に評価します。待ち時間が集中している箇所はどこか、またどのスレッドが繰り返し ピーク 。その後、それらがCPUの限界、ポリシーの競合、あるいは割り込みの嵐に起因するものかどうかを確認します。サンプリング時間は、まれな事象を捕捉できるほど十分に長く、かつ変更を個別に分析できるほど十分に短く設定しています。 マイクロ秒単位の値は日常業務では十分ですが、リアルタイムワークロードによっては、さらに厳しい許容範囲が求められる場合もあります。重要なのは、最大レイテンシが確実に低下し、ジッターが縮小しているかどうかです。.
レイテンシに影響を与えるLinuxスケジューラのパラメータ
まず、実行準備が整ったすべてのタスクがどの時間枠内で処理されるかを決定する目標レイテンシ「sched_latency_ns」を調整します。 CPU-時間を調整する。処理数が多い場合はタスクごとの時間スライスが縮小し、少ない場合は拡大する。これにより公平性は保たれるが、応答時間がずれる可能性がある。 対話型アプリケーションの場合、応答時間を短縮するためにこの値を適度に下げますが、その際はオーバーヘッドにも注意を払います。CFSは時間を公平に割り当てますが、クリティカルなスレッドを含むワークロードは、明確な優先順位設定によって恩恵を受けます。ホスティング環境におけるフェアスケジューリングの基礎については、以下にまとめます： CFSスケジューラの仕組みを理解する.
レイテンシやクォンタに加え、ウェイクアップの粒度やマイグレーションロジックも影響を及ぼす ヒント. 過度なデータ移動はキャッシュの局所性を損ない、間接的に待ち時間を長引かせる。 私は不要な移動を減らし、ホットスレッドをピン留めし、データをコアに近い場所に保持します。NUMA環境では、メモリへのアクセス距離がレイテンシを増加させるため、この点はさらに重要です。目標は、安定した予測可能なスケジューリング環境を維持することです。.
方針、優先順位、締め切りを賢く活用する
批判的なスレッドには SCHED_FIFO あるいは、スループットよりもレイテンシを優先する場合はSCHED_RRを採用します。SCHED_DEADLINEを使用すれば、期間、実行時間、デッドラインに沿ってリソースを正確に割り当てることができ、厳格な期限を確実に守ることができます。システムがリソース不足に陥らないよう、こうしたポリシーは控えめに適用しています。 優先順位は、真に不可欠なパスだけが通過するように調整します。優先順位に関する実用的な入門情報は、こちらをご覧ください： プロセスの優先順位.
バックグラウンドジョブがより高い Prio インタラクション・スレッドとして受け取ります。デッドラインパラメータも適切なサイズ設定が必要であり、そうしないと新たなボトルネックが発生します。実際のワークロードを用いたテスト実行により、選択の妥当性を確認します。私は変更点をすべて記録し、その影響を追跡することで、効果の経緯を明確に把握できるようにしています。そうすることで、運用時の予期せぬ副作用を回避しています。.
CPUの分離、ピンニング、NUMA：レイテンシの安定化
専用のCPUを分離し、システムサービスを低負荷な領域から遠ざけることで、重要なスレッドと一般的な負荷を分離しています。 レイテンシー が必要です。CPUピンニングは、ホットパスを特定のコアに固定し、キャッシュの局所性を確保します。NUMA構成では、ノードをまたぐ不要なアクセスを避けるため、スレッドをローカルメモリバンクにバインドしています。これらの対策により、ジッター効果が顕著に低減されます。 その効果は、eBPFヒストグラムの幅が狭くなることで即座に現れます。.
IRQの割り当てもその一環です。不要な割り込みをレイテンシコアの処理から迂回させることで、負荷を軽減しています。 ホット-スレッド。MSI-Xとアフィニティを活用することで、割り当てをきめ細かく制御できます。可能な限り、スレッド化されたIRQを採用し、ISRの処理を迅速に完了させます。これらすべてが、時間的制約のある実行に余裕を生み出します。perfやcyclictestを用いた測定結果からも、その効果が裏付けられています。.
割り込み、ドライバ、プリエンプションの最適化
ISR内の計算負荷の高い部分を後段のワークキューに移すことで、スケジューラの処理を高速化します 切り替える 。カーネル内の長いクリティカルセクションは、プリエンプションポイントがより頻繁に発生するように分割します。レイテンシを増加させる不要なカーネル機能や負荷の高いドライバは、無効にします。 ハードリアルタイムの場合は PREEMPT_RT を使用しますが、一般的なサーバー負荷であれば、適切な設定を施した PREEMPT で十分な場合が多いです。重要なのは、仮定に頼るのではなく、あらゆるチューニングを正確に測定することです。.
タイマーの分解能やティックオプションがワークロードに適しているかどうかを確認しています。というのも、粗いティックでは ジッター を向上させることができる。さらに、電力管理も重要だ。Cステートのレベルが低すぎると、復帰時間が長くなり、レイテンシの急上昇を招く可能性がある。ガバナーの設定を適切に調整することで、実用的な妥協点を見出せる。 結局のところ、重要なのは測定値の一貫性であり、オプションの名前ではありません。安定したアプローチは、過度な個別設定よりも優れています。.
実用的なチューニング手順と例示値
まずベース測定から始め、たった1つだけ変更を加えます パラメータ 各ループごとに、因果関係を特定します。その後、sched_latency_ns を微調整し、最大値とジッターを観察して、その影響を記録します。 必要に応じて、クリティカルなスレッドをピン留めしたりIRQを再割り当てしたりして、再度測定を行い、ピーク値を記録します。ポリシーが適合する場合は、FIFO/RRまたはDEADLINEに的を絞って切り替えます。以下の表は、一般的なオプションと、その効果および副作用をまとめたものです：
| オプション／機構 | レイテンシへの予想される影響 | 考えられる副作用 | ヒント |
|---|---|---|---|
| sched_latency_ns 下げる | CPUまでの待ち時間が短縮 | スケジューリングのオーバーヘッドの増加 | 小さな一歩、効果を測定する |
| ウェイクアップの粒度を調整する | ウェイクアップ後の引き継ぎが高速化 | プリエンプションの頻度が高まる | 調整は控えめに行う |
| CPUのピンニング／分離 | より安定した ピーク そしてジッターの低減 | 柔軟性の低下 | IRQの親和性を考慮する |
| SCHED_FIFO/RR | 好ましいデザイン | 他のタスクの優先順位を下げる | クリティカルパスに限定 |
| PREEMPT_RT | 低いワーストケース遅延 | 文脈の切り替えを増やす | RT対応のドライバーが必要 |
perf timehist と eBPF ヒストグラムを用いて変更内容を検証し、 流通 設定を厳密にしつつ、最大値は保守的なままにしておく。相反する効果が現れた場合は、一歩引き、別の組み合わせを試してみる。環境ごとに反応が多少異なるため、きめ細やかな実験が重要だ。一貫性のあるベンチマークを用いて、その有効性を客観的に立証する。こうして、再現性のあるチューニングプロセスが構築される。.
ホスティングおよびサーバーの文脈：レイテンシを効果的に低減する
ホスティング環境において、スケジューラの微調整を行うことで、Webおよび データベース-リクエスト。Runqueueの待ち時間が短縮され、ピークが解消されれば、多数の同時実行プロセスが恩恵を受けます。重要なサービスに優先順位が与えられ、CPUに近い位置に配置されるようになれば、コンテナおよびマイクロサービス・スタックの処理はより安定したものになります。 プロバイダーを選定する際は、最新のカーネル、適切なプリエンプション、柔軟なIRQ／CPU制御に注意を払う必要があります。レイテンシの低減は、売上とユーザー体験に直接寄与します。.
レイテンシに影響を与える最新のカーネル機能
最新のカーネルには、応答時間に直接影響を与える仕組みが導入されています。CFSは、新しいバージョンにおいて、インタラクティブな負荷を優先するように調整された、ウェイクアップおよび追い出しに関する洗練されたヒューリスティックが実装されました。次のような属性など、 覚醒・潜時選好 スレッドごとに、RTポリシーを悪用することなく、重要なパスをより迅速に実行できるようにします。さらに、 uclamp （utilization clamping）スケジューラが設定する、タスクまたはcgroupごとのCPU使用率の下限および上限。これにより、レイテンシが重要なスレッドに対して計算能力の下限を強制し、周波数ガバナーやアクティブなコアへの割り当てを制御します。.
ティック数の少ないシステムでは、私は以下を使用しています NOHZ_FULL 専用のハウスキーピング用CPUと組み合わせて使用します。これにより、定期的なカーネル処理がレイテンシの大きいコアから切り離されます。さらに、以下の方法でこれらのコアの負荷を軽減しています。 rcu_nocbs, 、コールバックによって処理のリズムが乱されないようにするためです。これら両方により、不適切なタイミングでのプリエンプションが減り、最悪ケースの値が安定します。.
と一緒に 生販在 (Pressure Stall Information) では、CPU、メモリ、I/O のシステム負荷を測定します。指標は /proc/pressure/* リソース不足によりスレッドが停止しているかどうかを示す。CPU-PSIがランキューの待ち時間と並行して増加する場合、それは真の過負荷、あるいはクォータ制御が厳しすぎることを明確に示している。.
Cgroups、コンテナ、フェアネス：オーバーヘッドのない分離
コンテナ環境において、Cgroupsはレイテンシを計画的に調整するための重要な手段です。私は CPU.weight, 、相対的な公平性を確保するために、そして利用して cpu.max, 、不要なバックグラウンドサービスを厳しく制限するためです。重要なサービスには厳しいCPUクォータが割り当てられないようにし、それらが スロットルをかける そして、時間的に細分化される。CPUに近い処理を実現するため、私はcpusetsを分割している。つまり、対話処理用のコア群と、バッチ処理用のコア群に分ける。この分離は、単なるNiceレベルの設定よりも効果的だ。.
オーケストレーション機能を備えたプラットフォームでは、レイテンシに敏感な複数のポッドが同じ物理コアを共有しないようにしています。コアを予約しています 独占 そして、関連するIRQを一貫してバインドします。cgroup階層の変化は、eBPFのcgroupフィルターを使って測定し、サービスごとのランキュー待ち時間を把握しています。これにより、ピークの根本原因が負荷分散にあるのか、それともクォータにあるのかを特定できます。.
仮想化とSMT：ホストノイズの検出と低減
VMでは、次の点に注意しています スティールタイム: これは、ハイパーバイザーがゲストシステムからCPU時間を奪うタイミングを示しています。perfで良好なパスが確認されているにもかかわらず、アプリがカクつく場合は、多くの場合「スティールタイム」が原因です。これを解決するには vCPUのピンニング 専用pCPUへの割り当て、オーバーコミット率の低減、およびI/Oスレッドを個別のコアに分離すること。レイテンシを一定に保つためには、pCPU＝vCPUとする予定ですが、そうでない場合、最悪ケースの予測はほぼ不可能です。.
と一緒に SMT （ハイパースレッディング）では、兄弟コアとコアリソースを共有しています。そのため、レイテンシの多い処理は、兄弟コアが空き状態のコアに割り当てるか、コア間の干渉を制限するコアスケジューリングオプションを利用しています。 厳しい目標がある場合は、重要なコアに対してSMTを選択的に無効にします。これにより、ポート、キャッシュ、実行ユニットにおける競合が軽減され、パフォーマンス向上が得られます。.
ストレージ、I/O、ネットワークパス：隠れたレイテンシの原因
スケジューラのレイテンシは、しばしばCPUの問題のように感じられますが、実際には リクレイム 或いは コンパクション. ダイレクト・リクレイムはスレッドを停止させ、長いピークを引き起こします。私は空きページプールを十分に確保し、適度な vm.swappiness, 、メモリアクセスが激しいスワップによって妨げられないようにするためです。Transparent Huge Pages の調整は保守的に行っています。カーネルが不適切なタイミングで大きなページを統合してしまうと、処理が中断されてしまいます。 マドヴァイズ THPは、インタラクションを妨げることなくスループットを向上させられる場所に配置します。.
ライトバックやジャーナルコミット間隔も、相互作用に影響を与えます。 ダーティ・リミットが大きすぎると、処理が好ましくない時間帯にずれ込み、小さすぎると頻繁なフラッシングのピークが発生します。私はパーセントではなくバイト単位で設定し、書き込みを分散させることで、CPUの待機時間がI/Oのピークと重ならないようにしています。.
ネットワークパスでは、次のように確認します ソフトIRQ, 、NAPI予算、およびパケットの束ね。GROの設定が過度に積極的すぎると、パケットごとのオーバーヘッドは減少するが、インタラクティブなレイテンシが長くなる可能性がある。RPS/RFSは負荷を適切に分散させるが、IRQおよびCPUのアフィニティと整合する必要がある。 目標は、パケットがアプリケーションスレッドが実行されている場所で処理されるようにすることであり、複数のコア間を移動させることを避けることである。.
RTのスロットリング、締め切り、および保護メカニズムのバランスをとる
仝 RTスロットリング このシステムは飢餓状態を防ぐ一方で、RT負荷をCPU時間の一部に効果的に制限します。確定的な応答時間を実現するために、私は kernel.sched_rt_runtime_us あるいは、厳重に隔離された環境ではその制限を無効にします。その際、RTスレッド以外のスレッドが十分なウィンドウを割り当てられているかどうかを徹底的に測定します。同様に重要なのがグローバルな 締め切り-割り当て：これが厳しすぎると、パラメータが正しく設定されていても、DEADLINEタスクはその実行ウィンドウを逃してしまいます。私は以下の比率を確認しています： 実行時 にとって period およびCPUごとのDEADLINE予約の合計。.
計測設計、回帰防止、および運用
測定フェーズは「ウォームアップ」「リファレンス」「バリエーション」「検証」と厳密に区別しています。キャッシュが冷えている状態では結果が歪むため、安定化したフェーズを測定し、PerfおよびeBPFデータと相関分析を行っています。 A/B比較は、同一のワークロード、同一の所要時間、および固定されたアフィニティで実行します。サンプリングウィンドウは、まれなピークが統計的に現れる程度の大きさでありながら、個々のチューニングステップを個別に評価できるほど十分に小さいものを選択します。.
連続運転用に、私は SLO レイテンシおよびジッターについて：Yの負荷条件下で、約99.9%分位数がXマイクロ秒未満。PSIからのテレメトリ、perf統計、およびeBPFヒストグラムが監視機能として機能し、 メトリクスが閾値を超えた場合、自動的に保守的なプロファイルに戻します。変更のたびに、カーネルバージョン、パラメータ、測定方法、生データ、および解釈を記載した変更履歴が作成されます。これにより、チューニングの再現性が確保され、いつでも元の状態に戻すことが可能です。.
- ベースラインの作成：perf、eBPF、schedstat、cyclictest
- ボトルネックの特定：CPU、IRQ、I/O、メモリ、ポリシー
- 1ラウンドにつき1つの変更：パラメータ、ピンニング、ポリシー、分離
- 測定前／測定後：平均値、99%および99.9%分位数、最大値
- 安定性の検証：長時間の実行、実際のワークロード、負荷のピーク
- 記録と保存：プロファイル、閾値、再発対策計画
簡単にまとめると
私は以下の方法でスケジューラのレイテンシを測定しています。 パーフェクト, eBPF、schedstat、cyclictestを、何か設定を変更する前に実行します。その後、目標レイテンシを慎重に下げ、ポリシーを調整し、ピンニングとIRQアフィニティによって重要なスレッドを隔離します。 ドライバ、ISRの分割、プリエンプションは、ワーストケースのピークを低減し、ジッタを最小限に抑えられるよう設定します。変更のたびに、測定結果を繰り返し確認し、曲線が納得のいくものになるまで検証を重ねます。こうして、 カーネル- 持続的な応答性を確保し、デスクトップ、サーバー、およびリアルタイムのワークロードに対して信頼性の高い結果を提供します。.
