サーバーと仮想マシン

LinuxスケジューラCFS：サーバーホスティングにおける機能と代替案

LinuxのスケジューラであるCFSは、サーバコアのプロセスへの時間割り当てを制御し、サーバホスティングにおけるレイテンシ、スループット、公平性に直接影響を与えます。このガイドでは、CFSがどのように機能するか、どのようにチューニングするか、そしてULE、BFS、EEVDFのような有用な代替案について説明します。 ホスティング をもって ウェブサーバー.

中心点

公平性 そして 稼働時間 どのタスクがCPUを使うかを決める。.
Cグループ ノルマを規制し CPUシェア 顧客の絶縁のために。.
カーネル・チューニング sched_latency_nsと粒度.
代替案 BFS、ULE、EEVDFのような特殊なもの ワークロード.
練習コア親和性、I/Oプランナー テスト を組み合わせる。

日常生活におけるCFSの働き

完全にフェアなスケジューラでは、仮想ランタイムが次に実行するタスクを決定し、その結果、次のタスクが実行される。 フェア そして予測可能 アロケーション が作成される。各タスクはnice値に比例してCPU時間を受け取るので、nice値が低いとより多くのシェアを受け取ることになる。ホスティング環境では、多くの小さなウェブリクエスト、cronjobs、バックアップが、一つのプロセスが全てを占有することなく、CPUを分割します。NGINXリクエストのようなインタラクティブなワークロードは、頻繁で短いタイムスライスの恩恵を受け、バッチタスクはより長いブロックを受け取ります。これは、多くのサイトが並列にリクエストを処理していても、レスポンスタイムがユーザーにとって信頼できるままであることを意味します。.

cpu.sharesとcpu.maxが明確なので、私はCgroupsを使って顧客とサービスを制限しています。 シェア合計 そして限界. .デフォルト値の “normal ”は1024シェア、“less important ”は512シェアで、コアをわかりやすく配分している。例えば、cpu.maxでは、100ms周期で50msを設定し、これは実質的に50%のCPUシェアに相当する。この設定は、負荷が変動するワークロードのホスティングに予測可能なリザーブを提供する。この原理についてのコンパクトな説明は、以下を参照されたい。公平なCPU配分.

CFSのメカニズムをわかりやすく解説

CFSの中核は、すべての実行可能なタスクを赤/黒のツリーで管理することである。 稼働時間 そして効率的な セレクション 最小の仮想ランタイムのこのタスクは次に実行され、消費されたCPU時間に比例してvruntimeを増加させ、nice値で重み付けされる。これにより、ハード・キューを使用しない流動的なバランスが作り出され、特にワークロードが混在している場合に、きれいな結果が得られる。マルチコアシステムでは、スケジューラはランキュー間でタスクを移動させるが、コアアフィニティによってキャッシュローカリティに注意を払う。このようにして、CFSは負荷分散と高価なマイグレーションを可能な限り少なくすることを両立させている。.

微調整のために、sched_latency_nsやsched_min_granularity_nsのようなパラメータがある。 レイテンシー そして スループット. .レイテンシーの値が小さいほど、短時間のインタラクティブなジョブが有利になり、値が大きいほどバッチジョブが有利になる。stress-ngやfioなどのツールを使ったテストでは、レスポンスタイムやCPU使用率への影響をチェックしている。タスクの数が増えれば増えるほど、ツリーの管理オーバーヘッドが増え、それがピークレイテンシとして現れます。しかし、ホスティング環境では、クォータと制限を正しく設定することで、これらの影響を抑えることができます。.

サーバーホスティングにおけるCFSの強み

最大の強みは 公平性, わかりやすく リソース 分散している。共有環境では、クォータとシェアが重み付けを明確に定義するため、どの顧客も他の顧客を永久に置き去りにすることはありません。インタラクティブなサービスには速いレスポンスタイムが与えられ、バックアップは慌てることなく実行できる。素敵な値による優先順位付けは、この図式を完成させ、サービスの役割に応じて調整する余地を残してくれる。すべてのコアでロードバランシングを行うことで、個々のスレッドのジェフ・モーメントにあまり余裕を与えることなく、利用可能なコンピューティングパワーを有効に活用することができる。.

実際には、ウェブサーバーのピークが発生し、多くの短いリクエストが届くと、CFSの強みが明らかになる。クリーンなCグループは、顧客やコンテナごとに厳しい上限を設定するのに役立ちます。平均値とパーセンタイルの測定は、信頼性の高いレスポンスタイムを示し、これは日々のビジネスで実を結びます。このアプローチは、多くのコンポーネントを持つアプリケーションスタックに特に有効です。予測可能な公平性と十分な柔軟性がミックスされることで、高いスコアが得られます。.

限界と典型的な障害

同時タスク数が非常に多い場合、ツリー演算のオーバーヘッドは増大する。 ヒント その レイテンシー はパフォーマンスを上げる可能性がある。非常に短いリクエストの多いホスティングセットアップでは、コンテキストが頻繁に変わることがあります。このような “srashing ”動作は、粒度の値が正しく選択されない場合、効率を下げます。インタラクティブ性が維持される限り、少ないが長いタイムスライスも有効である。CFSは不正なクォータに敏感に反応します。そのため、私は負荷テストで常に上限をチェックしています。.

アフィニティに適したワークロードであっても、タスクが頻繁にコア間を移動するようであれば、苦しくなります。クリーンなアフィニティ・コンセプトは、キャッシュを暖かく保ち、マイグレーション・コストを削減する。私はまた、ノイズの多いバッチジョブをそれぞれのコアにバインドして、ウェブリクエストがそれぞれのコアで静かに実行されるようにしたい。レイテンシが重要なサービスでは、低いナイス値と細かく調整されたレイテンシを設定する価値がある。最終的に重要なのは、選択したパラメーターを測定で確認することだ。.

代替案の比較：ULE、BFS、EEVDF

特別な仕事については、次のような代替案を検討する。 レイテンシー 或いは スケーリング 優先順位付けが異なる。ULEは、より単純なキューを使用し、より少ない管理労力で得点を稼ぎ、BFSは、応答性を優先し、少ないタスクで輝きを放ち、EEVDFは、公平な分配と期限を組み合わせる。特にEEVDFは、スケジューラが「許容される最も早い締め切り」にもっと注意を払うので、インタラクティブな負荷に対する待ち時間の短縮を約束する。非常に大規模なサーバー分野では、最終的に本当に重要なのは、あなた自身のスタックにおいて、効率性と計画性のどのミックスが本当に勝つのかということである。長所、短所、適用分野を構造的に検討することが、選択の助けになる。.

スケジューラ	複雑さ	ホスティングにおける強み	弱点	こんな人に向いている
まんせいひろうしょうこうぐん	高い	公平な分配、, Cグループ	遅延ピーク	共有ホスティング、混合負荷
ユーリー	低い	シンプルな合図、低い負荷	断熱性が低い	VM、HPCのようなパターン
ビーエフエス	ミディアム	双方向性、, スピード	弱いスケーリング	デスクトップ、小型サーバー
イーブイディーエフ	ミディアム	低遅延、, 締め切り	まだまだ練習不足	最新のホスティングスタック

カーネル・チューニング：CFSのための実践的ステップ

CFSでは、scheduled_autogroup_enabled=0に切り替えることが多い。 負荷分散 クリア残骸. .sched_latency_nsでは、インタラクティブなサービスが有利な20msから始めて、sched_min_granularity_nsでコンテキストの変化を調整したい。値はプロファイルに依存する。多くの短いウェブリクエストは、バックアップウィンドウとは異なる微調整が必要だ。私は変更を連続的にテストし、平均値を見る代わりにパーセンタイルを測定します。こうすることで、平均値がきれいに見えるだけでなく、長いキューが縮小することを保証します。.

sysctlパラメーターについてもっと深く知りたい場合は、こちらが参考になる： sysctl チューニング. .私はまた、CPUが常に経済的な状態に傾かないように、IRQ分配、CPUガバナー、エネルギープロファイルを調整する。私は、レイテンシ主導のスタックにはパフォーマンスガバナーを使用し、純粋なバッチボックスにはバランス制御を使用します。テスト段階と本番段階を明確に分け、サプライズがないようにしている。各ステップの後、次に進む前にログとメトリクスをチェックする。.

cグループとクォータを賢く使う

cpu.sharesで、相対的な ウェイト cpu.maxがハードな間 バウンダリー のセット。512株の顧客は、1024株の顧客の半分の計算時間を得る。私はcpu.maxを使ってピークをきれいに制限しています。例えば、100msで50msです。専用ジョブの場合、cpuset.cpusは、サービスが固定コアを使用し、キャッシュが暖かいままであるように、価値がある。全体として、これは顧客とサービスの間の弾力的な分離につながる。.

私はすべての変更を文書化し、達成したいサービスレベルと比較します。測定値がなければ、共有はすぐに誤った解釈につながります。そのため、私は常に負荷テストを伴う調整を行っています。コンテナについては、ピークに対応しつつホストの速度を落とさない現実的なクォータを提案します。顕著なレイテンシーのピークを検出できるように、予測可能なエラーバジェットを持つことが重要であることに変わりはない。これを一貫して行えば、ピーク時の驚きを避けることができる。.

実践：CFS下のウェブサーバーとデータベース

イベント駆動型のウェブサーバーは、コンテキストスイッチを減らし、CFSと調和させる。 応答時間 より良い スケーリング を生成しました。テストでは、NGINXは同じハードウェア上でより少ないジッタでより高いリクエストレートを維持することがわかりました。データベースは、バックグラウンドジョブをホットコアから遠ざけると、コアアフィニティにポジティブに反応します。シンプルなルールが役立ちます：ウェブはA-Bコア、バッチはC-Dコア、DBはE-Fコア。こうすることで、スタックはパイプラインをクリーンに保ち、キャッシュを暖かく保つことができる。.

小規模なPHP FPMワーカーが多く、積極的な粒度でスイッチが多すぎます。そこで最小のタイムスライスを増やし、レスポンスタイムが安定しているかチェックする。同時に、I/Oがブレーキにならないようにチャットログをスロットルする。ここではCFSが基礎となるが、スタック全体を微調整することでピーク・パフォーマンスが達成される。こうすることで、ホストの息の根を止めることなく、すべての歯車が連動する。.

メモリI/OとCPUスケジューリング：相互作用

CPUスケジューラとI/Oスケジューラは互いに影響し合うため、調和されたセットアップが顕著な違いを生む。 メリット に於いて レイテンシー を持ってくる。NVMeの場合は通常Noopかmq-deadlineを使うが、HDDの場合はmq-deadlineの方が長いキューに対応できる。CPUが時間通りに時間を割り当てても、I/Oパスがストールすれば、全体の効果は打ち消される。そこで、CFSパラメータと並行してI/Oスケジューラをチェックしている。Noop、mq-deadline、BFQの概要についてはこちらで説明している： I/Oプランナーの比較.

データベースホストの場合、CFSがスケジュールしたスロットがI/Oのブロックのために空回りしないように、キューの深さとリードアヘッドを調整する。多くの小さなファイルを扱うウェブサーバボックスは、I/Oスタックのレイテンシが低いという利点がある。仮想化シナリオでは、予測不可能なパターンを避けるために、ホストとゲストの一貫したスケジューラに依存している。これは、CPUスケジューラがストレージサブシステムとどのように相互作用するかということだ。最終的に重要なのは、リクエストからレスポンスまでのコヒーレントチェーンである。.

SMPバランシング、コアアフィニティ、NUMA

私はスレッドを固定コアに誘導し、次のようにする。 キャッシュ 温暖化と移住コスト 小さい のままです。NUMAホストの場合、リモートメモリアクセスはレイテンシを増加させるので、私はメモリとCPUを一緒に固定する。CFSはランキュー間の負荷分散を行うが、意図的なアフィニティルールによって、より多くの効果が得られることが多い。キャッシュに頻繁にアクセスするサービスは、安定したコアグループから恩恵を受ける。バッチジョブは、ホットコアに干渉しない限り、ローミングが許可されている。.

実際には、cpuset.cpusとnumactlオプションを設定し、リクエスト時間とCPUミス率をテストする。不要なマイグレーションが少ないほど、レスポンスタイムは向上する。IRQのピークがコアを詰まらせないように、割り込みの配分も評価する。こうして、重要なスレッドのクロッキングをスムーズにする。この落ち着きは、全体的なスタック性能で実を結ぶ。.

グループ・スケジューリング：ナイス、重み付け、ヒエラルキー

ホスティングでよくつまずくのは交流間 nice-優先順位と Cグループのウェイト. .CFSはまずグループ間で公平に分配し、次にグループ内でタスク間で公平に分配する。つまり、グループ（クライアント/コンテナ）のウェイトが低ければ、ナイス-5のプロセスでもナイス0のプロセスより少ないCPUしか得られない可能性がある。そのため、一貫した結果を得るために グループ・ウェイト そして、サービス内での微調整にのみナイスを使用する。.

実際には、いくつかの明確なレベル（例えば、“low/normal/high ”で512/1024/2048株）を設定し、どのサービスがどのグループで実行されているかを文書化する。これにより 公平性 階層で追跡可能です。また、短時間のプロセス（CGI/CLIジョブなど）を多く扱う場合にも、次のような利点があります。 cグループベース そうしないと、揮発性タスクが意図せずにグループ・コルセットをバイパスしてしまうからである。私は定期的にランタイム・メトリクスを使って、内部割り当てがまだ負荷プロファイルに合っているかどうかをチェックしている。.

コンテナとオーケストレーション：リクエスト、制限、スロットリング

コンテナ環境では、“リクエスト ”は通常次のようにマッピングされる。比重 (株／重量）の「制限」である。 ノルマ (cpu.max）。相互作用は スロットリングクォータが厳しすぎると、コンテナCPUの処理速度が期間内に落ちてしまう。そのため、通常のバーストが期間内に収まるようにクォータを維持し、サービスが強くスロットルされることはほとんどありません。利用可能な場合は バースト-reserve (例：cpu.max.burst)は、歪みなく短いピークを緩和する。.

リクエストを低く設定しすぎないことが重要である：ウェイトが低すぎると、インタラクティブなサービスはバッチノイズに遅れをとってしまう。私は、測定された基本負荷と安全な制限に基づいて、以下のようにリクエストを調整する。 エラー予算 がピーク時に維持される。マルチテナントノードの場合は、個々のコンテナの負荷ピークが隣接するコンテナに影響を与えないように、バッファコアも計画する。.

スケジューラーのコンテキストにおける測定方法とトラブルシューティング

私はCFSの調整をやみくもに評価することはなく、的を絞って測定している。私は概要のために使っている：

ランキューの長さ CPUあたり（負荷対アクティブコア）、,
コンテキストの変更 毎秒とスレッド数、,
CPUスティール そして ソフトアイアールキュー-シェア,
パーセンタイル 応答時間の（p50/p95/p99）、,
分布 稼働時間 またはスケジューリングの待ち時間。.

待ち時間のピークが発生した場合、私はまず、以下を探す。 スロットリング (ノルマを消化）した後移住 (キャッシュコールド）、そして最後に I/Oブロック (キューの深さ、ストレージの飽和）。ウェイクアップパターンを見る：多くのワーカーが頻繁に短時間ウェイクアップする場合は、粒度が細かすぎるか、I/Oがおしゃべりであることを示している。あるコアでksoftirqdの割合が増加している場合は、IRQキューがホットになっていることを示しています。この場合はIRQを分散してRPS/XPSをアクティブにし、ネットワーク負荷がより広く分散されるようにします。.

リアルタイムクラス、プリエンプション、ダニ制御

CFSに加え、以下のリアルタイムクラスが存在する。 SCHED_FIFO/RR. .RTスレッドが正しく設定されていないと、文字通りシステムから空気が抜けてしまう。そのため、私はRT-Prioを非常に選択的にしか割り当てず（例えばオーディオ/テレメトリー）、明確なウォッチドッグも定義しています。ホスティングの場合は、クリーンウェイトのCFSで十分です。.

宛先 先取り先取りモデルの選択（例えば、“voluntary ”と “full/dynamic preempt”）によって、レイテンシ／スループット比が変わる。ウェブスタックではより多くの先読みを、純粋なバッチホストではより少ない先読みを好む。ティック最適化 (ノーズ-modes）はジッターを減らすことができるが、使用には注意が必要である。孤立したコアでは、私は時々 nohz_full ホットスレッドが可能な限り邪魔されずに動作するように、システム負荷やIRQ負荷が不用意にこれらのコアに移行しないようにすることが重要です。.

仮想化：KVM、vCPUのピニングとステイルタイム

ハイパーバイザー環境では、ホストのスケジューラーが、いつ vCPU を実行できる。オーバーブッキング スティールタイム これは “見えないレイテンシ ”のようなものです。レイテンシが重要なテナントに対しては、vCPUを物理コアに固定し、オーバーコミットを控えめにしています。また、エミュレーターのスレッド（IOスレッド、vhost）とゲストのホットコアを分離し、互いに干渉しないようにしています。.

ゲストがすでにcpu.maxを使用している場合、同じワークロードに対してホストに追加のハードクォータを設定しません。周波数制御はホストのタスクのままです。ホストのガバナーが実際のワークロードに合わせてきれいにスケールすれば、ゲストは間接的に恩恵を受けます。レイテンシが均一であるためには、純粋な最大周波数を超えた安定性の方が、ピークGHzよりも重要だと考えています。.

AutoNUMA、メモリーローカライゼーション、THP

NUMAは性能向上にも性能の罠にもなり得る。. オートヌマ 多くの場合助けになるが、激しくローミングするスレッドではさらにオーバーヘッドが発生する可能性がある。明確なサービス境界を持つホスティングスタックでは、CPUと メモリ (cpuset.cpus そして cpuset.mems)を一緒にする。これは、ホットデータがローカルに残り、CFSは少ないマイグレーションを補う必要があることを意味する。.

大きなページTHP)はTLB-Pressureを低下させるが、すべてのプロファイルに適合するわけではない。データベースの場合、一律に「常に」よりも「マッドバイス」の方が理にかなっていることもある。そのため、CFSスロットが生産的に使用され、I/OやMMUイベントを待たないようにバッファ（ページキャッシュ、共有バッファ）を計画する。これは、ページフォルトレートとキャッシュミスカーブで測定できる。.

ネットワークパス：IRQ制御、RPS/XPS、ビジーポーリング

多くのウェブワークロードはNICが支配的です。私は 割り込み要求-ネットワーク・カードのキューを複数のコアに分散させ、それらを保持する。 アフィン をワーカースレッドに渡すことで、ウェイクアップをローカルに保つことができる。. RPS/XPS は、個々の RX/TX キューが過大な負荷を運んでいる場合に、ソフトのホットスポットを解決するのに役立つ。ksoftirqd が目に見えて熱くなるようであれば、これは SoftIRQ がオーバーフローしていることを示している。.

オプションのビジーポーリングは、非常に特殊な低レイテンシーのセットアップでは意味がありますが、CPU時間がかかります。私はめったに使用せず、ホストにストレスを与えずにp99が大幅に低下することを測定によって証明できる場合にのみ使用する。通常は、クリーンなIRQアフィニティ、Cgroups、CFSの粒度の方が、費用対効果に優れています。.

展望：CFSからEEVDF、そしてユーザー空間へのアプローチへ

EEVDFは公平な配分を期限まで拡大する。短いより予測しやすい回答約束する。特にインタラクティブなレイテンシターゲットでは、これがすべての違いを生む可能性がある。私はカーネルのバージョンを注視し、切り替える前にEEVDFを個別にテストしている。同時に、eBPFパターンによるユーザースペースのスケジューリングが勢いを増している。CFSはホスティングインフラにとって依然として重要だが、EEVDFはすぐに地位を確立するだろう。.

テスト、選択したホストへのロールアウト、そして拡張。これがパーセンタイルとエラーレートをコントロールし続ける唯一の方法です。私は、バーストフェーズや低速バックエンドを含め、ベンチマークを現実に近いものに保ちます。そうして初めて、私はライブ環境に介入する。こうすることで、厄介なサプライズを起こさずに進歩を遂げることができる。.

簡単にまとめると

Linux Scheduler CFSは、公平な配布、堅実な統合、そして優れた機能を提供します。 コントロール 経由 Cグループ. .適切なsysctlパラメータ、クリーンなアフィニティ、現実的なクォータで、私はレイテンシを低く、スループットを高く保っている。ULE、BFS、EEVDFは、特殊なパターンにさらに力を発揮します。私はリスクを限定するために、段階的に測定、比較、変更を展開します。これにより、ホスティングは予測可能な状態に保たれ、パフォーマンスは本来あるべき状態に保たれます。.