サーバーと仮想マシン

カーネルスケジューラのティックレスモードの解説：メリット、リスク、およびチューニング

私が説明するのは、 ティックレスモード Linuxカーネルの仕組みをわかりやすく解説し、それがパフォーマンス、レイテンシ、消費電力にどのような好影響を与えるかを示します。その上で、明確なメリット、考えられるリスク、そして私が実際に実践し、その有効性を確認してきた具体的なチューニング手順について説明します。.

中心点

最も重要なことをまとめる。 主要テーマ 要点をまとめてあるため、何に注意すべきかがすぐにわかります。Linuxのスケジューラとダイナミックティックは密接に連携し、あなたの CPU. ワークロードに応じて、Tickless Idleで十分か、それともコアを分離したFull Ticklessを使用するかを判断します。再現性のある結果を得るために、ハウスキーピング用CPU、IRQアフィニティ、RCUコールバックを適切に計画します。最終的に重要なのは、あなたの環境におけるレイテンシ、消費電力、スループットの測定値です。 セットアップ 本当に示す。.

ティックレス・アイドル: アイドル時のティック数が少ない
NO_HZ_FULL: 静かで人里離れた地域
IRQアフィニティ: ノイズ源を集中させる
CPUピン止め: スレッドを固定する
測定値: レイテンシ、エネルギー、ジッタ

このリストには、私が最初に確認し、組み合わせていく調整レバーが記載されています。これにより、どこに最も大きな レバー にあるか、そしてカーネルをどの程度カスタマイズするか。.

カーネル・ティックが実質的にどのような効果をもたらすか

定期的なティックにより、カーネル内で時間計測、タイマー管理、および新しい スケジューリング-決定。これは単純な仕組みですが、有意義な作業が待っていない場合でもカーネルを起動させます。ティックレス方式では、カーネルは必要に応じて次の起動を計画し、不必要な 割り込み. これにより、CPUはより長く深いCステートに留まり、レイテンシが重要なタスクにおけるジッターを低減します。私はこの仕組みを利用して、敏感なスレッドのために安定した実行ウィンドウを確保しています。.

バリエーション：「Tickless Idle」と「NO_HZ_FULL」の概要

ティックレス・アイドル (CONFIG_NO_HZ_IDLE) を設定すると、CPU がアイドル状態になると定期的なティックが抑制されます。これにより、プロセッサがディープスリープ状態から呼び出される頻度が減るため、消費電力と発熱が低減されます。. NO_HZ_FULL さらに、アクティブなコアでタスクが1つしか実行されていない場合でも、ティック数を削減します。そのため、これらのコアを厳密に隔離し、システム処理を専用のハウスキーピング用CPUに移行します。適切な隔離を実現すれば、コアの動作音を大幅に低減でき、その結果、負荷がかかった際の動作予測性が向上します。.

比較表と活用シナリオ

以下の概要は、私にふさわしいものを選ぶのに役立ちます。 モード 目的に応じて選択し、必要な環境を適切に整える必要があります。私はまずワークロードの特性、次にエネルギー目標、そして最後にジッター許容度を確認します。経験上、特にトレーディング、HPC、および非常に低レイテンシの ネットワーク-スタックを無効にします。一方、負荷変動の激しいデータセンターでは、多くの場合、「Tickless Idle」が最も迅速にコスト削減効果をもたらします。「Full Tickless」は、システム処理を確実に切り離せる、厳格に管理されたホストにのみ適用するようにしています。.

モード	いつ有効になるか	メリット	リスク	こんな人に向いている
周期的なティック	常に、一定のHzレート	シンプル管理	ジッターとウェイクアップの増加	一般的なサーバー
ティックレス・アイドル (NO_HZ_IDLE)	アイドル時のみ	エネルギー消費が少なく、より涼しい CPU	レイテンシの低減効果は限定的	VMホスト、Web、混合
フル・ティックレス (NO_HZ_FULL)	シングルタスクの負荷時でも	非常に静かな中心部、少ないジッター	入念な断熱が必要	HPC、トレーディング、リアルタイムに近い

ティックレス・モードが真価を発揮する時

アプリケーションが極端に 低遅延 対応する必要がある。これには、注文マッチング、シングルキューによるパケット処理、あるいは科学計算コードにおける厳密なNUMAローカライゼーションなどが含まれる。混合ホスト環境におけるエネルギー目標の場合、多くの場合、ティックレスアイドル状態によって測定可能な貯蓄. スリープフェーズが多く表示される場合は、ティックによってCステートから抜け出すことが少なくなるため、大きなメリットがあります。ぜひ私のガイドもご覧ください。 Ticklessによるエネルギー効率化, 、とりわけ電気代を節約したいのであれば。.

日常生活における利点と副作用

周期的なティックが少なければ、それだけ コンテキストの変更 また、多くの場合、実行時間がより安定します。分離構成ではOSノイズが低減されるため、感度の高いコードの動作がより一貫したものになります。Linux Foundationおよびカーネルドキュメントによると、NO_HZ_IDLEはアイドル時のパフォーマンスを大幅に向上させ、一方NO_HZ_FULLはノイズパルスをさらに低減します。 HPC関連の資料では、ハウスキーピングカーネルにおけるピンニングやIRQバンドリングとの組み合わせによる効果が確認されています。測定を適切に設定すれば、これらの効果はレイテンシやエネルギープロファイルにおいて明確に確認できます。 ホスト.

不適切なチューニングによるリスク

IRQやRCUコールバックが、結局のところ分離されたカーネルに割り当てられてしまい、その休息破壊してしまう。そうすると、干渉負荷が非協調的に発生してジッターが生じるため、その利点は失われてしまう。隔離されたCPU上で動作する予定外のバックグラウンドサービス、タイマー、あるいはウォッチドッグも、同様に干渉を引き起こす。また、多数の短いタスクを含む混合ワークロードも、不安定さを広範囲に分散させるため、フルティックレス方式の効果がほとんど得られません。そのため、私はハウスキーピング用コアを明確に割り当て、現実的なシナリオで各ステップをテストしています。 プロフィール.

重要なカーネルオプションをわかりやすく解説

と一緒に config_no_hz_idle アイドリング時にこの機能をオフにすれば、大がかりな改造をせずに素早く性能向上を図ることができます。. config_no_hz_full これは、コアを厳密に分離し、クリーンなハウスキーピング用CPUを定義する場合にのみ有効にします。ブートパラメータ「nohz_full」は、どのコアをティックレスで動作させるかを指定し、「isolcpus」はそれらを一般的なスケジューリングから切り離します。 rcu_nocbsは、これらのコアからRCUコールバックを排除し、irqaffinityは割り込みの割り当てを設定します。これらを組み合わせて初めて、この設定は安定し、真に 役に立つ.

ハウスキーピングのコアを計画する

1～2つ予約します カーン 各NUMAノードを、IRQ、カーネルスレッド、およびRCUのためのハウスキーピングゾーンとして割り当てます。これらのコアは、避けられないシステムタスクを処理し、隔離されたコアを解放した状態に保ちます。そのため、サービスとIRQキューを意図的にハウスキーピング用CPUにピン留めし、低負荷のコアではそれらを無効にしています。この CPUスケジューラクラス理解し、優先順位と公平性を確実に管理します。これにより、レイテンシ経路が短く保たれ、安定したコアが予測可能な 応答時間.

実践ガイドステップバイステップ

私はどのプロジェクトも、明確な ベースライン-Run：レイテンシ、消費電力、スループット、ジッター。その後、NO_HZ_IDLE が有効かどうか、およびカーネルが NO_HZ_FULL をサポートしているかどうかを確認します。次に、IRQアフィニティを割り当て、rcu_nocbsを設定し、ハウスキーピング用CPUをスケジューリングします。その後に初めて、テストとしてnohz_fullを使用して少数のコアを隔離し、結果を比較します。詳細な分析には、以下のガイドが参考になります。レイテンシの測定, 、そうすれば、あらゆる変更を正確に評価できるようにするためです。.

測定方法とKPI

私はエンドツーエンドのレイテンシー ヒストグラムを用いて、単に平均値を見るだけでなく、外れ値を四分位数で分類します。PPSとテールレイテンシは、負荷の低いコアがスループットを低下させないよう、合わせて評価します。消費電力はRAPL、IPMI、または接続したメーターで測定し、節約量を ユーロ 月あたり。例：1台のホストが24時間365日の稼働で12 Wの電力を節約した場合、0.30 €/kWhとすると、1台あたり月約3.15 €の節約になります。ホストが200台あれば、その合計は月630 €という目に見える金額になります。.

深く掘り下げて：カーネルが実際にティックを無効にする仕組み

Ticklessの背景には、周期的なティックから ワンショット・クロックイベント: カーネルは、次の「イベント」を、タイマーまたはスケジューラの決定が実行される最も早い時刻に正確に設定します。高解像度タイマー（hrtimer）を使用することで、きめ細かな粒度を実現できます。ある NO_HZ_FULL-CPUでは、タスクが1つしか実行されておらず、カーネル処理が発生していない限り、定期的なスケジューラティックは発生しません。 2つ以上のタスクが実行可能になると、カーネルは公平性とタイムスライシングを確保するために、再びティックを開始します。まさにこの動的な仕組みによって、スケジューリングの正確性を損なうことなく、システムの動作音を低減させているのです。.

HZ、ハイレゾタイマー、および時間アカウント

カーネル定数 HZ (通常 250 または 1000) は、従来のティックの周波数を決定します。「Tickless」を設定すると、実行時間が重要なコアにとって HZ の実用的な重要性は薄れますが、jiffies ベースのロジックにとっては依然として重要です。また、重要なのは 時間配分 (VTIME/コンテキスト追跡)：ユーザ時間とシステム時間が正しく記録されるよう、カーネルは、恒常的なティックを使用せずに、タスクがカーネル空間にあるかユーザ空間にあるかを正確に追跡します。プロファイリングを頻繁に行う場合は、測定結果を正しく解釈するために、この点を念頭に置いておく必要があります。.

省電力機構とティックレス

Ticklessの省エネ効果は、プラットフォームが深い Cステート 確実に達成されています。そこで、intel_pstate/amd-pstate、ターボモードに関するファームウェアおよびカーネルの設定を検証しています。 cpufreq-ガバナー。アグレッシブなパフォーマンス・ガバナーはレイテンシを低減できるが、電力目標の達成を妨げる可能性がある。逆に、パワーセーブ・ガバナーの動作が鈍すぎると、スループットが低下する恐れがある。私のアプローチ：まずティックレス設定を安定させ、その後、それぞれ同一のワークロードプロファイルを用いて、PステートおよびCステートのチューニングを体系的にテストする。.

仮想化とコンテナ

ハイパーバイザーホスト上では ティックレス・アイドル 休止状態のvCPUが起動される頻度が低くなるため、多くの場合、すぐにコスト削減効果が実感できます。 NO_HZ_FULL 物理コアを分離し、重要なVMのvCPUをそのコアに正確に割り当てます。重要：スティールタイムやホストIRQがこれらのコアの動作を妨げてはなりません。ゲスト環境において、フルティックレスが有効なのは、ホストがCPU時間を決定論的に割り当てる場合に限られます。コンテナ環境では、以下の方法で分離ロジックを再現します。 cgroups CPUセット また、システムポッドやサイドカーが低負荷のコアを占有するのを防ぎます。.

ネットワークおよびストレージのパスを安定させる

超低レイテンシーを実現するために、私は RX/TXキュー そして、それらのIRQをハウスキーピング用CPUに割り当てます。負荷の低いコアでは、IRQを許可するのではなく、ユーザースペースポーリングや専用のコンプリートスレッドを使用することを好みます。NVMeの場合、 IOキューアフィニティ 同様の効果があります。NAPIビジーポーリングは、ポーリングジッターが割り込みジッターよりも予測しやすい場合に、意図的に活用できます。その目的は、分離されたコアが外部イベントによって予期せずウェイクアップされることが決してないようにすることです。.

例：ブートパラメータとピンニング

以下に、最小限のセットアップの概要を示します（例：16コア、CPU 0～1をハウスキーピング用、2～7および10～15を負荷対象候補、8～9をシステムサービス用）：

GRUB_CMDLINE_LINUX="nohz_full=2-7,10-15 rcu_nocbs=2-7,10-15 isolcpus=2-7,10-15 irqaffinity=0-1"

ボートの後、AffinityとCPUsetsを一貫して適用しています：

#のIRQを束ねる
for i in $(grep -E 'eth0|nvme' /proc/interrupts | awk -F: '{print $1}'); do
  echo 3 > /proc/irq/$i/smp_affinity_list   # CPU 0-1
done

# レイテンシに敏感なサービスをピン留めする
taskset -c 2-3 /usr/bin/mein_service

# システムサービス用の cgroup-cpuset（例）
mkdir -p /sys/fs/cgroup/cpuset/housekeeping
echo 0-1,8-9 > /sys/fs/cgroup/cpuset/housekeeping/cpuset.cpus
echo 0 > /sys/fs/cgroup/cpuset/housekeeping/cpuset.mems
echo $$ > /sys/fs/cgroup/cpuset/housekeeping/cgroup.procs

systemd-Unitでは、補足として以下を使用しています CPUAffinity= 或いは AllowedCPUs=, 、サービスが常に適切なカーネを使用できるようにするためです。.

診断：カーネルが本当に静かかどうかを確認する

ほんの数ステップでコアのアイドル状態を確認します： – /proc/interrupts：孤立したCPUでカウンタが増加していますか？もしそうなら、IRQアフィニティを修正します。 – /proc/timer_list: NO_HZ_FULLカーネル上で予期しないタイマーを特定します。 – ftrace/perf: ウェイクアップ、ソフトIRQ、およびスケジューリングイベントを表示します。 – turbostat: C-Stateの滞在時間を確認します。アイドル状態のコアでソフトIRQ（NET_RX、TIMER）が発生している場合、そのほとんどは割り当てまたはドライバの問題です。.

PREEMPT_RT および RT-Threads との連携

PREEMPT_RT プリエンプションをカーネルの深部まで組み込むことで、レイテンシを低減します。NO_HZ_FULLと組み合わせることで、IRQがスレッドとして実行され、ハウスキーピング用CPUに厳密に限定されている場合、非常に良好な結果が得られます。重要：RTスレッドを広く分散させるのではなく、厳密に固定し、そのメモリパス（NUMA、ページフォールト）を管理してください。私は、2つ目の実行可能タスクが発生してティックが戻ってくることがないように、隔離されたコア上のRTスレッドを常に「単独」で実行しています。.

「フル・ティックレス」が割に合わない場合

以下の場合は、NO_HZ_FULLの使用を控えます： – 短命なタスクが絶えず発生する場合（例：Fork/Execのバースト）。 – ワークロードの同期が激しく、絶えずカーネルスイッチが強制される場合。 – プラットフォームがクリーンなC-Stateに到達しない、またはTSCが不安定な場合。このような場合、クリーンな IRQおよびCPUのピン割り当て 多くの場合、全面断熱にかかる手間よりもはるかに大きい。.

生産における細部：モニタリングと運用

本番環境では、「知らず知らずのうちに」行われる変更に注意を喚起しています。カーネルの更新、新しいエージェントの導入、あるいはIRQマッピングの変更などが、カーネルの安定性を損なう恐れがあるからです。そこで、私は以下の対策を講じています： – 再起動後にアフィニティ、CPUセット、RCU設定を確認する「ガードレール」スクリプト。 – ウェイクアップ数/秒、Cステート滞在時間、p99.9レイテンシに関するメトリクス。 – 定期的な 回帰テスト 同一のワークロードで。そうして初めて、ティックレス方式の利点を確実に維持することができます。.

ジッターの原因を的確に解消する

IRQに加え、しばしば ユーザースペースのタイマー (sleep/usleep/timerfd) は不安定なパターンに使用します。私は タイマー・スラック (prctl または /proc) を使用し、期限をまとめて処理することで、カーネルがスケジュールする個別のウェイクアップの回数を減らします。また、マネージドランタイム（JVM、Go）におけるバックグラウンドGCについても、タイミングを調整するか、ハウスキーピングカーネルに隔離するようにしています。目標は常に、NO_HZ_FULL コアでは、絶対に必要なウェイクアップのみを許可することです。.

KPIの解釈：トレードオフを可視化する

私は平均値だけでなく、その流通: p50、p95、p99.9、および最大値。典型的な成功パターンとしては、テールレイテンシが大幅に低下し、平均スループットは横ばいまたはわずかに上昇し、C-State滞在時間が長くなる。一方、ジッターは改善されているものの、スループットが著しく低下している場合は、CPUの周波数ポリシーを調整するか、キューが詰まらないようアイドル状態のコア数を慎重に増やします。.

NO_HZ_FULL を有効にする前のチェックリスト

– カーネル機能：CONFIG_NO_HZ_FULL、高解像度タイマー有効
– CPUの役割の明確化：NUMAノードごとにハウスキーピング用CPUを定義
– IRQ および RCU のオフロード：irqaffinity および rcu_nocbs を一貫して設定
– サービスの配置：systemd/cgroupsのピンニングについて、ドキュメント化およびテスト済み
– 測定環境：再現性のあるワークロード、有意義なKPI、比較 前／後
– ロールバック計画：NO_HZ_FULL なしでも利用可能なブートエントリ

よくある落とし穴と対処法

システムサービスが隔離されたコア上で実行されているのをよく見かけますが、その断熱その問題を解消するには、systemd-Affinity、cgroups-CPUsets、そして明確なサービスドキュメントが役立ちます。また、NUMAの配置ミスも、不要なリモートアクセスやレイテンシの急上昇を引き起こします。私はメモリとスレッドを各ノードに厳密に紐付けることで、パスを短く一貫性のあるものにしています。滞在. IRQの割り当てが不明確なのは3つ目の典型的な問題であるため、アクセス頻度の高いキューをハウスキーピング用CPUに集約している。.

実践のための簡単なまとめ

仝 ティックレス カーネルは、不要なティックを削減し、電力を節約するとともに、高精度が求められるワークロードに対して信頼性の高い時間枠を確保します。「Tickless Idle」を使用すれば効率の向上がすぐに得られ、「Full Tickless」は分離されたコアにさらなる静粛性をもたらします。 IRQ、RCU、およびバックグラウンド処理をハウスキーピング用CPUに適切に集約することで、最大の効果が得られると考えています。測定なしでは何も始まりません。レイテンシ、ジッター、消費電力、スループットを測定することで、チューニングが効果を発揮しているかどうかがわかります。このようにして、ティックレスモードを的確に活用し、システムから最大限のパフォーマンスを引き出しています。 スケジューラ アウト。