プロンプトと対象となる職種
Linux 6.12およびcgroup v2を実行する16 vCPUサーバーが、オフライン圧縮ジョブとともにレイテンシに敏感なAPIをホストしています。オフラインジョブが開始された後、APIのp99は45msから600msに増加します。ホストのモニタリングでは全体のCPU使用率は約78%と報告されており、APIはわずかなCPU時間しか累積していません。関連するAPIおよびオフラインジョブのスレッドはすべてSCHED_OTHERを使用しています。
現代のLinuxフェアスケジューラが実行可能（runnable）スレッドの中からどのように選択するかを説明し、以下の原因を区別する検証可能な診断プロセスを提示してください：
- APIスレッドは実行可能状態にあるが、CPUの割り当てを過剰に待たされている。
- APIのcgroupが
cpu.maxのquotaによってスロットリングされている。 - アフィニティまたはcpusetにより、処理がビジー状態の少数のCPUに制限されている。
- APIスレッドが実際にはmutex、I/O、またはその他のイベントでスリープしている。
- より優先度の高いリアルタイムスレッドが通常のスレッドの実行を妨げている。
この設問は、Linuxランタイムの知識を必要とするSRE、インフラ、システムソフトウェア、パフォーマンスエンジニアリング、バックエンドの職種に適しています。16、6.12、45ms、600ms、78%という値は架空の演習用入力値であり、普遍的なキャパシティやアラートのしきい値ではありません。
面接官がテストしていること
最初の境界はタスクの状態です。スケジューラが選択できるのは実行可能（runnable）スレッドのみです。mutex、ネットワーク操作、ディスク操作、またはタイマーでスリープしているスレッドは、CPUのランキューで待機しているわけではありません。その全区間をスケジューリング遅延とラベル付けしてはなりません。候補者はまず、スレッドがすでに実行可能状態であったかどうかを答える必要があります。
第2のレイヤーはフェアスケジューリングモデルです。歴史的なCFSの説明では、仮想実行時間（vruntime）を使用して「理想的なマルチタスキングCPU」を近似し、vruntimeが小さいエンティティを優先します。現在のEEVDFモデルでもlagと呼ばれる公平性の負債を追跡し続けますが、適格（eligible）なエンティティのみを許可し、その中で最も早い仮想デッドライン（earliest virtual deadline）を選択します。nice値やcgroupのweightは長期的な相対シェアに影響します。要求スライス（request slice）と仮想デッドラインは、タスクが次に実行機会を得るまでの早さに影響します。どちらのメカニズムも、個々のリクエストに対して固定のp99を保証するものではありません。
第3のレイヤーは階層構造とローカルな制約です。ホストに22%のアイドルキャパシティがあっても、ターゲットcgroupがハードquotaを使い果たしている場合や、スレッドが飽和した2つのCPUに閉じ込められている場合があります。cpu.weightは競合時にアクティブな兄弟cgroup間での相対的なweightであるのに対し、cpu.maxは周期ごとにハードな帯域幅上限を課します。タスクグループやcpusetにより、ホスト全体の集計値が局所的なスタベーションを隠蔽することがあります。
第4のレイヤーは直接的な証拠です。/proc/12345/schedstatからのランキュー待機時間、perf sched timehistからのrunnableからrunningへの遅延、そしてcgroupのcpu.statおよびcpu.pressureは、集計CPUやコンテキストスイッチ数単体よりもメカニズムに直接迫る指標です。優れた回答では、トレースの権限、オーバーヘッド、期間の制限についても考慮されます。
最後に、候補者には緩和策の境界線が求められます。APIをSCHED_FIFOに移行すると通常の処理に割り込む（preempt）ことができますが、無限ループやロック保持者によってマシン全体がスタベーションに陥るリスクがあります。修正は証拠に従う必要があります。不適切なquotaの修正、兄弟weightの調整、CPUセットの修復、あるいはスレッドがrunnableでなかった場合のロックやI/Oパスの調査などです。
回答前に確認すべき明確化の質問
- p99の計測はどこで開始し、どこで終了しているか？ イングレスのキューイング、アプリケーションの実行、ダウンストリームの待機、クライアントのネットワーク時間を分離し、ホストのサンプリングを同じ区間に揃えます。
- ターゲットスレッドはいつrunnable状態になっているか？ スレッド状態、off-CPUの理由、またはスタックを取得します。CPU時間が少ないことは、スケジューリングの欠如または長期のスリープを意味する可能性があります。
- APIとオフラインジョブはどのようなcgroup階層に含まれているか？ 両者の
cpu.weight、cpu.max、親のリミット、cpu.statを比較します。親cgroupも子cgroupを制約します。 - どのCPUで処理の実行が許可されているか？ スレッドのアフィニティ、
cpuset.cpus.effective、CPUごとの使用率、およびNUMAレイアウトを確認します。16 vCPUホストだからといって、スレッドが16個すべてを使用できるとは限りません。 - リアルタイムスケジューリングエンティティは存在するか？
SCHED_FIFOおよびSCHED_RRの処理について優先度とCPUアフィニティを調査します。プロンプトでは関連するビジネススレッドがSCHED_OTHERを使用しているとしか述べられておらず、ホスト上の無関係なリアルタイムスレッドは除外されていません。 - オフラインジョブがロック、メモリ、またはI/Oパスに影響を与えたか？ 圧縮処理はCPUの競合を引き起こすだけでなく、メモリ回収（reclaim）、ファイルI/O、または共有ワーカープールでのキューイングを激化させる可能性があります。
- 短いトレースをキャプチャできるか？
perf schedは通常、追加の権限を必要とし、記録オーバーヘッドを発生させます。まず低オーバーヘッドのカウンタで方向性を確認し、制御されたウィンドウ内で15秒間サンプリングします。
30秒の回答フレームワーク
「低速なリクエストの最中に、APIスレッドがすでに実行可能（runnable）状態であったかどうかをまず確認します。ロックやI/Oでスリープしている時間はoff-CPUの待機です。スケジューリング遅延とは、runnableになってから実際に実行（running）されるまでの区間を指します。
Linux 6.12では、fairクラスをEEVDFの観点から説明します。EEVDFは理想的な公平サービスに対する各エンティティのlagを追跡し、適格（eligible）なエンティティを対象として、最も早い仮想デッドライン（earliest virtual deadline）を選択します。CFSの最小vruntimeモデルは歴史的な直観としては依然として有用ですが、現在の選択ルールを完全には説明していません。niceとcpu.weightは相対シェアを変更し、cpu.maxは直接スロットリングでき、アフィニティやcpusetは利用可能なCPUを制御します。
CPUごとの使用率、スレッド状態、cgroup設定を調査します。次に、/proc/12345/schedstatのランキュー待機差分、cpu.statのスロットリング差分、およびcpu.pressureを比較します。証拠が依然としてスケジューリングを指している場合は、短いperf schedトレースをキャプチャしてrunnableからrunningへの遅延を直接測定します。修正後は、78%の集計CPUから原因を推測するのではなく、同じ負荷を再生してAPIのp99、スケジューリング遅延分布、スロットリング、CPUプレッシャー、オフラインのスループットを総合的に検証します。」
ステップバイステップの詳細解説
ステップ1: 実行可能（Runnable）とスリープの境界を明確にする
CPUが別のタスクを必要とするとき、LinuxスケジューラはそのCPU上で実行可能、またはそこへ移行（migrate）する資格のあるエンティティのみを選択します。通常のポリシーのスレッドはスケジューリング優先度が0です。リアルタイムのSCHED_FIFOおよびSCHED_RRスレッドは、より高い静的優先度範囲を使用し、通常のスレッドに割り込むことができます。
したがって、APIのCPU時間が少ないことには根本的に異なる2つの説明があります：
- スレッドはrunnableであるが、ランキューの競合、quota、またはCPUセットの制限により速やかに実行されない。
- スレッドはfutex、ソケット、ディスク、タイマー、またはアプリケーションキューでスリープしており、イベントが到着して初めてrunnableになる。
まずスレッド状態とスケジューリングポリシーを調査します：
ps -eLo state,cls,rtprio,pri,ni,psr,pid,tid,comm --sort=-rtprio,-pri
pidstat -t -w -u -p "$pid" 1 10psは瞬間的なスナップショットであるため、単一のRやSでは問題を断定できません。pidstatのコンテキストスイッチとCPUデータはターゲットスレッドの特定に役立ちますが、コンテキストスイッチ数が多いこと自体はスケジューリング遅延が大きいことを証明しません。スレッドがほとんどスリープしている場合は、アプリケーションのトレース、ロックプロファイリング、off-CPUスタック、I/Oメトリクス、ダウンストリームレイテンシを調査してウェイクアップ条件を特定します。
ステップ2: CFSで直観を掴み、モデルをEEVDFへアップデートする
従来のCFSの説明では、各fairエンティティの実際の実行時間をそのweightによってスケーリングし、vruntimeに変換します。weightが大きいエンティティほどvruntimeの蓄積が遅くなります。vruntimeが小さいエンティティを選択することで、長期的なサービス提供を設定されたweightに近づけます。これは理解を助ける直観として依然として有用であり、niceが公平なシェアを変化させる方向性を説明できます。
Linuxカーネルのドキュメントによると、fairクラスは6.6でEEVDFへの移行を開始しました。簡潔な回答には2つの概念を使用できます：
lagは、理想的な公平サービスに対してエンティティにどれだけのサービスが負われているか、または受領済みかを表します。lag >= 0を持つエンティティが適格（eligible）となります。- 適格なエンティティの中から、スケジューラは最も早い仮想デッドラインを選択します。要求スライスが短いほどデッドラインが早くなり、レイテンシに敏感な処理の応答機会が向上します。
EEVDFは公平性とレイテンシのトレードオフを処理しますが、負荷のweightから固定のミリ秒SLAが導かれるわけではありません。実際の待機時間は、利用可能なCPU、エンティティ数、weight階層、quota、ウェイクアップのタイミング、上位のスケジューリングクラスに依存します。面接では、歴史的な直観としてCFSのvruntimeを使用し、Linux 6.12のプロンプトで求められているEEVDFの選択ルールで締めくくります。
ステップ3: Nice、相対Weight、ハードQuota、CPUセットを切り分ける
SCHED_OTHERの場合、通常のnice範囲は-20から19であり、Linuxはnice値をスレッドごとに保持します。niceはfairクラス内での相対的なweightを変更します。CPUを予約するわけではなく、cgroupのリミットを解除することもできません。タスクグループスケジューリングでは、異なるcgroup内のエンティティはまずグループレベルで競合します。グループ内の1つのスレッドをreniceしても、2つのcgroup間のシェアをほとんど変更できない場合があります。
cgroup v2の3つの制御は異なる問いに答えます：
cpu.weightはデフォルトが100で、1から10000の範囲です。競合するCPUサイクルをアクティブな兄弟間で比例配分します。cpu.maxは$MAX $PERIODの形式をとり、デフォルトはmax 100000です。数値の最大値が指定されると、期間の予算を使い果たした後にcgroup全体をスロットリングします。cpuset.cpus.effectiveは、階層構造とシステム状態が適用された後に実際に利用可能なCPUセットです。
ホスト、スレッド、ターゲットcgroupの制約を読み取ります：
mpstat -P ALL 1 10
taskset -pc "$pid"
cat /sys/fs/cgroup/api/cpuset.cpus.effective
cat /sys/fs/cgroup/api/cpu.weight
cat /sys/fs/cgroup/api/cpu.max
cat /sys/fs/cgroup/api/cpu.stat
cat /sys/fs/cgroup/api/cpu.pressure低速リクエストの期間中にcpu.statのnr_throttledとthrottled_usecが増加している場合、そのcgroupは帯域幅制限に達しています。ハードなグループ予算は、他のホストCPUがアイドル状態であってもそのグループを停止させることがあります。2つのメトリクスはスコープが異なります。quotaカウンタに変化がなくても、cpuset.cpus.effectiveが2-3のみであり、CPU 2と3が飽和している場合、78%というホスト平均値は同様にミスリーディングです。
ステップ4: RunnableからRunningへの待機時間を直接測定する
代表的な低速スレッドを選択した後、そのスケジューリングカウンタを2回読み取ります：
cat /proc/"$tid"/schedstat
sleep 5
cat /proc/"$tid"/schedstat3つのフィールドは、CPU上で実行された累積ナノ秒、ランキューで待機した累積ナノ秒、取得したタイムスライスの数です。累積合計ではなく、読み取り間の差分を使用します。実行時間が少ないのに2番目のフィールドが急増している場合は「runnableだが速やかに実行されていない」ことを裏付けますが、その理由を説明するには依然としてquota、アフィニティ、優先度の高いスレッドの調査が必要です。
分布とタイムラインが必要な場合は、システム全体の簡単なトレースを取得します：
sudo perf sched record -a -- sleep 15
sudo perf sched timehist --state --summaryperf sched timehistは、ウェイクアップ、マイグレーション、CPUをタイムライン上に配置しながら、待機時間、runnableからrunningへのスケジューリング遅延、実行時間を表示できます。本番環境では、まずカーネルのサポート、権限、ディスク容量、許容可能なオーバーヘッドを確認してください。収集ウィンドウを制限し、不要になったトレースデータは削除します。テールの事象を逃した1回の15秒のサンプルだけではスケジューラをシロと判定できません。再現可能な前後比較を通じて分布を比較します。
ステップ5: 識別力のある証拠を用いて5つの原因に絞り込む
以下のマトリクスを使用して原因を絞り込みます：
| 証拠の組み合わせ | 方向性 | 次に確認すべき証拠 |
|---|---|---|
高いランキュー待機時間とperf schedの遅延、高いCPUプレッシャー、スロットリングなし | Fairクラスのランキュー競合 | CPUごとのキュー、weight、バッチ並行度、マイグレーション |
p99とともにnr_throttledとthrottled_usecが上昇 | cgroupのハードquota枯渇 | 親および子のcpu.maxとキャパシティ予算 |
| 一部のCPUが100%で他がアイドル、有効cpusetが狭い | アフィニティ/cpusetのホットスポット | ピニングの意図、NUMA配置、マイグレーション範囲 |
| スレッドがほとんどスリープしており、ランキュー待機時間が低い | ロック、I/O、タイマー、アプリケーションキューの待機 | Futex/off-CPUスタック、I/O、ダウンストリームトレース |
| 優先度の高いFIFO/RRスレッドが同一CPU上で長時間実行 | リアルタイムスケジューリングのスタベーション | リアルタイム優先度、ランタイム、ロック、アフィニティ |
cpu.pressureは、CPUの競合によってrunnableな処理が進められない時間を測定します。これはCPU競合がワークロードに影響を与えている有用な証拠ですが、不十分な相対weight、quotaによるスロットリング、不適切なピニングを区別することはできません。cpu.stat、アフィニティ、スケジューラトレースによってその区別を完結させます。
リアルタイム処理は個別の優先度パスを辿ります。SCHED_FIFOスレッドは、ブロックされるか、より優先度の高いリアルタイムスレッドにプリエンプトされるか、自ら譲る（yield）まで実行されます。SCHED_RRは、同一のリアルタイム優先度を持つスレッド間でのみクォンタムを追加します。通常のスレッドが、継続的にrunnableな高優先度リアルタイムスレッドより優先されるようなfairクラスのweightは存在しません。
ステップ6: 実証されたメカニズムを修正し、ビジネスおよびスケジューラメトリクスの両方を検証する
それぞれの緩和策は、確認されたメカニズムに対応している必要があります：
- 不適切なquota: キャパシティと隣接プロセスへの影響を評価した上で、誤った
cpu.maxを引き上げるか削除する。 - 不十分な相対シェア: API cgroupのweightを増やす、オフラインcgroupのweightを減らす、またはオフラインタスクのnice優先度を下げる。
- 不適切なCPUセット: NUMAとキャッシュ局所性を確認しながら、cpusetまたはアフィニティを拡張または再バランスする。
- Fairクラスの競合: オフラインの並行度を制限する、バッチを分割する、または適切なオフライン処理に
SCHED_BATCHやSCHED_IDLEを使用する。 - スリープ待機: ロック競合、ワーカープール、I/O、メモリプレッシャー、ダウンストリームサービスを修正する。スケジューラのチューニングは通常効果がありません。
- リアルタイムスタベーション: 不要なリアルタイムポリシーを削除し、実行時間を制限し、優先度逆転とロックの依存関係を調査する。
同じリクエストレートとオフライン負荷で前後比較を実行します。少なくともAPIのp50/p95/p99とエラー、スレッドごとのスケジューリング遅延分布、schedstatのランキュー待機差分、cgroupスロットリング、CPUプレッシャー、CPUごとの使用率、オフラインスループットを検証します。APIのp99の改善によって、オフラインジョブが恒久的にスタベーションに陥ったり、ダウンストリームサービスや他のテナントに負荷が転嫁されたりしてはなりません。
優れた回答例
「ホストのCPU平均が78%であっても、スケジューラに問題がないとは言えません。Linuxはスレッドをスケジュールし、制約はスレッド、CPU、またはcgroupレベルに存在し得るからです。まず、遅いリクエストを処理しているスレッドがrunnable状態であるかどうかを確認します。futexやI/Oでスリープしている場合、CPU時間が短い主な理由はウェイクアップ待ちであり、スケジューラが選択できなかったことになります。
プロンプトではLinux 6.12が指定されています。CFSのvruntimeは公平性の直観を説明しますが、現在の選択はEEVDFで説明すべきです。スケジューラは理想的なサービスに対するlagを追跡し、lag >= 0を持つエンティティを競合させ、最も早い仮想デッドラインを選択します。niceとcpu.weightは長期的な相対シェアを変更し、cpu.maxはハードな周期的上限を設定し、アフィニティとcpusetは適格なCPUを制限します。これらのメカニズムのいずれも、45msのp99を自動的に保証するものではありません。
mpstat -P ALLを実行し、API cgroupのcpuset.cpus.effective、cpu.weight、cpu.max、cpu.stat、cpu.pressureを読み取ります。遅延の発生期間を通じてnr_throttledとthrottled_usecが増加している場合、quotaによるスロットリングが直接観察されたことになります。ホストのアイドルキャパシティはこの結論を変えません。処理がCPU 2と3に制限され、それらのCPUが100%になっている場合は、まずローカルのCPUセットを修復します。
スロットリングやピニングの異常がない場合は、代表的なTIDに対して/proc/12345/schedstatの読み取りを2回行い、ランキュー待機の差分を計算します。再現可能な負荷のもとで、perf sched recordを短時間キャプチャし、timehistでrunnableからrunningへの遅延、ウェイクアップ元（waker）、CPUを調査します。ランキュー待機時間が短く、スリープ時間が長い場合は、ロック、I/O、アプリケーションキュー、ダウンストリームトレースの調査に切り替えます。
証拠によりAPI cgroupが20000 100000として設定されており、スロットリングがp99と連動して上昇していることが判明したとします。測定されたキャパシティを用いて予算を修正し、オフラインの並行度を制限します。単にAPIをSCHED_FIFOに移行することはしません。再テストでは同じトラフィックとバッチジョブを使用し、オフラインのスループットが許容範囲に留まり、どのタスクもスタベーションに陥らない状態で、APIのp99、スケジューリング遅延、スロットリング、CPUプレッシャーが揃って低下することを確認します。」
よくある間違い
- 78%のホストCPUをCPU問題がない証拠として扱う → 平均値はcgroup quotaやローカルなCPUセットを覆い隠す → CPUごと、cgroup、スレッドの各ビューを総合的に調査する。
- すべてのoff-CPU時間をスケジューリング遅延と呼ぶ → スリープ中のスレッドはまだrunnableではない → 状態、スタック、トレースを使用して、まずウェイクアップポイントを特定する。
- 「CFSは最も小さいvruntimeを選択する」とだけ説明する → fairクラスはLinux 6.6でEEVDFへの移行を開始した → 適格なlagと最も早い仮想デッドラインを説明する。
cpu.weight=200が2つのCPUを予約すると想定する → weightは競合下でアクティブな兄弟間の相対シェアを表す → キャパシティは個別に設計し、ハード上限にはcpu.maxを使用する。- niceがすべてのコンテナを直接順序付けると想定する → タスクグループはまずcgroup階層で競合する → スレッドのniceを変更するか判断する前にグループのweightを確認する。
- 多数のコンテキストスイッチからスケジューラレイテンシを推測する → 通常のI/Oや並行処理でもスイッチは発生する →
schedstatのランキュー待機時間とperf schedの遅延を測定する。 - APIの安易な解決策として
SCHED_FIFOを使用する → 高優先度のリアルタイムスレッドは通常の処理をスタベーションに追い込み、ロックのリスクを増大させる → リアルタイムポリシーは、真のデッドラインがあり、実行時間が制限され、安全性の完全な分析がある場合にのみ検討する。 - quotaを確認せずにAPIのweightを引き上げる → cgroupは
cpu.maxに達した後に依然としてスロットリングされる →cpu.statでスロットリングを証明し、リミットを修正する。 - APIのp99のみを確認する → 変更によってバッチジョブがスタベーションに陥ったり、他のテナントが劣化したりする可能性がある → 公平性、スループット、プレッシャー、エラーも検証する。
フォローアップの質問と回答
フォローアップ 1: ホストにアイドルCPUがあるのにcgroupがスロットリングされるのはなぜですか？
cpu.maxは、その周期中にそのcgroupが消費するCPU帯域幅を制限します。予算を使い果たした後は、他のグループが使用していないCPUがアイドル状態であっても、そのグループは次の周期まで待機します。cpu.maxを調査し、同一区間におけるcpu.statのnr_throttledとthrottled_usecの差分を比較します。これらの値は、ホスト全体の集計使用率よりも直接的にハードリミットが発動したかどうかを明らかにします。
フォローアップ 2: APIスレッドをreniceしても効果が薄いのはなぜですか？
Linuxはniceをスレッドごとに適用しますが、グループスケジューリングでは、異なるcgroupはまずグループweightを使用してスケジューリングエンティティとして競合します。reniceは主にグループ内でのスレッドのシェアを変更します。親のcpu.maxを解除することはできず、APIグループとオフライングループの間の比率を変更できない可能性があります。スレッドのniceまたはグループのcpu.weightを選択する前に、cgroupの階層構造とweightをマッピングしてください。
フォローアップ 3: APIをSCHED_FIFOに移行すればp99は解決しますか？
ターゲットスレッドの待機時間は短縮されるかもしれませんが、より大きなリスクをもたらします。継続的にrunnableなFIFOスレッドは、通常のfairクラスのすべての処理を抑制する可能性があります。スピンしたり、ロックを保持したり、自身がスタベーションさせている通常スレッドに依存したりすると、システム全体の処理が停止する可能性があります。リアルタイムポリシーを評価するのは、処理に真のデッドラインがあり、ランタイムが厳密に制限され、優先度逆転が処理され、フォールバック保護が存在する場合のみにしてください。
フォローアップ 4: EEVDFは1つのスライス内でのCPUサービスを保証しますか？
いいえ。仮想デッドラインは適格なスケジューリングエンティティを順序付け、スライスはレイテンシの選好を表現します。利用可能なCPU、エンティティ数、weight、quota、アフィニティ、上位のスケジューリングクラスが依然として実際の待機時間に影響します。EEVDFは公平性とレイテンシのバランスをとるためのスケジューラメカニズムを提供するものであり、ビジネス上のp99 SLAではありません。
フォローアップ 5: Mutexの待機とランキューの待機をどのように切り分けますか？
mutexを待機しているスレッドは通常スリープし、ロックが解放された後にrunnableになります。ランキュー待機はrunnableになった後に開始されます。アプリケーションまたはeBPFのoff-CPUスタックおよびfutexやロックのメトリクスを、/proc/12345/schedstatおよびperf sched timehistと時間的に揃えます。ランキュー待機が低くfutexスリープが長い場合はロックが原因であることを示し、runnableからrunningへの遅延が大きい場合はスケジューリングやリソース制御が原因であることを示します。
フォローアップ 6: CPUピニングが実際に効果を発揮するのはどのような場合ですか？
適切に設計された分離は、例えばキャパシティテスト済みのCPUをレイテンシに敏感なスレッド専用に予約することで、マイグレーション、キャッシュの破壊、ノイジーネイバーを減らすことができます。CPUセットが十分に大きいこと、割り込みやバックグラウンド処理が統制されていること、CPUごとのキューが監視されていることが条件となります。不適切なピニングは、ホストのキャパシティがアイドル状態のまま局所的な輻輳を引き起こすため、CPUごとの使用率とスケジューリング遅延で結果を検証してください。