...
ウェブホスティングのロゴ

ティックレス・カーネルとエネルギー効率：サーバーを最適化する方法

A ティックレス・カーネル は、不必要なCPUウェイクアップを減らし、負荷がかかっても応答性を損なうことなく、サーバーのエネルギー要件を積極的に低減します。を最小化する方法を順を追って説明します。 カーネル を設定し、測定値を読み取り、パフォーマンスと電気代が明らかに調和するようにワークロードを計画する。.

中心点

以下の点は、最も重要なステップと相関関係の概要である。.

  • ダニなし タイマー：周期的ティックの代わりに要求制御割り込み
  • エネルギー セーブする：深いC状態を長く維持し、ウェイクアップを減らす
  • NO_HZ オプションCONFIG_NO_HZ_IDLEおよびCONFIG_NO_HZ_FULLを使用する。
  • スケジューラ 微調整：バンドルロード、割り込みアフィニティ設定
  • モニタリング 第1回：明確な効果を得るためのビフォー・アフター測定

チックレスモードの簡単な説明

古典的なLinuxカーネル は各CPUを一定間隔で、多くは1秒間に100回から1000回起動させる。このコストは エネルギー, タスクが保留されていなくてもである。ティックレス・モードは、この周期性を要求制御タイマー割り込みに置き換えたものである。その結果、イベントが実際に発生するまで、CPUはより長くディープスリープ状態を維持する。1]によると、不要なウェイクアップがなくなり、熱負荷が軽減されるため、まさにこの動作が効率を高めるのだという。私は、システムの負荷が大きく変動し、アクティビティとレストをきれいに切り替える必要がある場合に、ティックレスを使用しています。.

ティックレスがエネルギー効率を高める理由

CPUがアイドルのままであれば、低電圧を防止するために使用されるリジッドティックが使用される。 Cステート そして、常にコアを覚醒させた。その結果 廃熱 とファンを強制的に高速回転させた。Ticklessはこの永久的な目覚まし時計をなくし、アイドルフェーズを延長します。私は、ワークロードが変動するウェブやAPIホストで、アイドルモードでの消費電力が下がり、温度カーブが滑らかになることを確認しました。大規模なサーバー・ファームでは、ノードあたりの小さな節約は、電気代に換算するとユーロ単位の顕著な金額になります。プラットフォームはより静かになり、負荷ピークはより確実に緩和されます。.

モードとカーネル・オプション一覧

私は主に2つのアプローチを区別している：ティックレス・アイドルとティックレス・フルである。ティックレス・アイドルは、保留中のタスクがない限り、定期的に一時停止し、そのタスクを再生する。 強さ 特にアイドル・フェーズにおいて。ティックレス・フル（NO_HZ_FULL）は、動作中でも選択したコアのティックを減らし、レイテンシとコンテキスト・スイッチを減らすことができる。最近のディストリビューションでは、デフォルトでNO_HZ_IDLEが有効になっていることが多いですが、NO_HZ_FULLは特定のチューニングが必要です。一方、NO_HZ_FULLは特定のチューニングが必要である。 メリット 不規則な目覚めによって空回りすることはない。.

モード/オプション 効果 こんな人に向いている 備考
config_no_hz_idle アイドルモードでのダニをサスペンドする アイドルフェーズのある一般的なサーバー負荷 多くの場合、デフォルトでアクティブ。 リスク
config_no_hz_full 動作中のコアごとの刻みを最小化 低レイテンシ、HPC、選択されたコア クリーンコアの絶縁とIRQアフィニティ プラン
isolcpus、rcu_nocbs 低ノイズコア、少ないRCUウェイクアップ リアルタイムに近いワークロード 絶縁するコアはごくわずかで、残りのコアは絶縁している。 システム負荷
カーネル≧現在のLTS 新しい省エネパス、修正 すべての生産システム 1]による修正と効率化 使う

ステップバイステップ：カーネルとブートパラメータの設定

まず、カーネル機能の目録から始めよう。カーネルがチックレスをサポートしているかどうかは、設定フラグでわかる：

grep NO_HZ /boot/config-$(uname -r)
grep HIGH_RES_TIMERS /boot/config-$(uname -r)
grep -E 'CPU_IDLE|INTEL_IDLE' /boot/config-$(uname -r)

NO_HZ_IDLEの場合、通常はディストリビューション・カーネルで十分だ。NO_HZ_FULLの場合は、システムタスク、IRQ、RCUコールバックを引き継ぐハウスキーピングCPUを特に定義する。通常、CPU 0-1をハウスキーピングとして残し、残りのコアをDyTickモードに設定する：

# GRUB-CMDLINEの例（ハードウェアに合わせる）：
GRUB_CMDLINE_LINUX="nohz_full=2-15 isolcpus=2-15 rcu_nocbs=2-15 irqaffinity=0-1 nmi_watchdog=0"

重要：少なくとも1つのコアはハウスキーピングを維持しなければならない。そうしないとRCUがストールするリスクがある。GRUBの設定を更新して再起動した後、アクティブな設定をチェックする：

cat /sys/devices/system/cpu/nohz_full #はNO_HZ_FULL CPUをリストアップする。
cat /sys/devices/system/cpu/isolated # は孤立した CPU をリストアップします。
cat /proc/cmdline # はブートパラメーターを確認します。

また、高解像度タイマーとアイドル専用ドライバー（intel_idleなど）も有効にしている。どちらもタイマーのきめ細かさとスリープ状態の深さを向上させる。irqbalanceを使用する場合は、アフィニティが分離されたCPUに戻らないように、ロックされたコアを構成する：

#の例：例：/etc/irqbalance/irqbalance.envのIRQBALANCE_BANNED_CPUS
IRQBALANCE_BANNED_CPUS=0x0003 # CPU 0-1は許可、残りはブロック（システムごとのマスク形式）

次に、CPUごとの次のウェイクアップを見ることで、ティックが本当にないことを確認する：

sudo cat /proc/timer_list | grep -A2 '次のイベント' | sed -n '1,60p'

静かな局面では、次のイベントは明確に未来にあるか、タイマーがない場合はまったくないはずだ。.

測定規律：ツールと主要数値

測定がなければ、どんな最適化も盲目のままだ。私は基本値を記録し、変更のたびに比較する。その価値は証明されている：

  • パワートップWakeups-from-idle/s、トップオリジネーター、Cステートレジデンシー
  • ターボスタットフリークエンシー、パッケージとコアのCステート、RAPLのパフォーマンス
  • パースタットコンテキストスイッチ、タイマー割り込み、サイクル、命令
  • /proc/interruptsCPUごとのIRQ分配
  • pidstat/iostatプロセスおよびI/O特性
# アイドルモードで10分間のベースラインをキャプチャする
sudo turbostat --Summary --interval 5 --quiet --show PkgWatt,BUS,CPU,CPU,CPU,MHz
sudo powertop --time=600 --html=/tmp/powertop_baseline.html

#割り込みヒートマップ
watch -n2 'cat /proc/interrupts | sed -n "1,30p"'.

# コンテキストスイッチとタイマーイベント
perf stat -a --delay 5000 --timeout 60000 -e cs,task-clock,cpu-clock,irq_vectors:local_timer

それぞれのケースについて説明します：アイドル時の消費電力（PkgWatt）、Cステートのシェア、ウェイクアップ/秒、関連するワークロードのレイテンシ・メトリクス（p95/p99）。わずかな違いでも、数週間もすれば顕著になります。.

仮想化、コンテナ、チックレスのスタック

ハイパーバイザーとゲストは一緒になって多くのものを生成する。 タイマー とウェイクアップを、例えばcron、ロギング、エージェントを通して行います。私は、ハイパーバイザーとゲストシステムでTicklessを有効にすることで、この連鎖を減らしています。これにより、二重のウェイクアップがなくなり、仮想CPUはより長く静かに保たれる。Kubernetesやマイクロサービス環境では、バックグラウンド・ノイズのレベルが著しく低下する。また、ポッドとバッチの時間を同期させることで、より長いアイドルウィンドウが作成され 貯蓄 上昇する。.

KVM環境では、vCPUのピン止めとIRQアフィニティを一緒に計画する。大音量のvNICやvBlockのIRQをハウスキーピングCPUにバインドし、静かなワークロードは分離されたコアにバインドする。ゲスト側では、余計なタイマーソースを停止し、cronの頻度を減らし、イベントがより自然にバンドルされるように、精度に余裕のある（AccuracySec）systemdタイマーを使用しています。これにより、アイドルフェイズが長くなり、VMの終了とエントリーが少なくなるため、ハイパーバイザーは2倍の恩恵を受けることになる。.

実践的なセットアップ：パワープロファイル、ガバナー、割り込み

普段は素早い反応にガバナーを使っている スケジューティル ロードジャンプを動的にインターセプトするからだ。極端に短いレイテンシが優先されない限り、Cステートをアクティブにしておく。ノイズの多いIRQを選択したコアにバインドし、他のコアは深くスリープできるようにフリーにしておく。バッチジョブ、バックアップ、アップデートをブロック単位でスケジュールし、静かなフェーズを束ねる。もっと詳しく知りたい方は、以下のサイトに背景情報があります。 CPU周波数スケーリング, チップを惜しみなく使うために、私はティックレスと緊密に連携している。.

また、ブーストが必要なときだけ起動し、アイドル状態が高いまま維持されるように、最近のCPUのエネルギー優先バイアス（EPP/EPB）を調整しています。耐性のあるレイテンシーを持つサービスは、より大きなタイマースラック値(systemd: TimerSlackNSec=)を受け取り、私はsystemdタイマーを介して周期的なジョブをAccuracySecとRandomisedDelaySecで制御します。 これにより、エッジの負荷が減り、より長く連続したアイドルウィンドウが作成されます。.

#の例です：IRQ を具体的に割り当てる (注意: IRQ 番号を確認してください)
echo 0-1 | sudo tee /proc/irq/XX/smp_affinity_list # IRQ をハウスキーピングにバインドする。

# systemd のタイマーを協調的に設定する（.timer ユニットを抜き出す）
AccuracySec=5min
RandomisedDelaySec=30min
持続的=true

NUMAとロードバンドリングを賢く使う

マルチコアおよびNUMAホストでは、以下のようにします。 効率性, 意図的にいくつかのコアに負荷を集中させるのだ。その結果、フリーのコアはCステートに深く長く落ち込む。不必要な負荷上昇を避けるため、メモリアクセスはNUMAローカルに保つようにしている。Linuxのスケジューラーも役立つが、ホットスレッドの手動ピン止めが最後の仕上げになることが多い。Ticklessでは、孤立したコアはピリオディックで目覚めることがないため、このピン止めはより効果的である。 休息 を持つ。

実際には、I/O負荷の高いスレッドを同じNUMAノードに割り当て、CPU負荷の高いサービスをこのノードの数コアに分離するのが好ましい。Cグループ（cpuset、cpu）は、明確な境界線を引くのに役立つ。私は、ワークロードに応じてTransparent Huge PagesとAutoNUMAをチェックしている。少なくとも1つのノードは、システムタスクがクリティカルコアにバーストするのを防ぐのに十分なハウスキーピング能力を保持していることが重要だ。.

レイテンシー要件のバランスと測定

リアルタイムまたはトレーディングのワークロードの中には、可能な限り短い時間を必要とするものがある。 応答時間. .そのため、本番に近いサンプルでテストを実施し、ティックレス変更前後のレイテンシ・パーセンタイルを比較している。NO_HZ_FULLはコンテキストの変更とタイマーノイズを減らすことができるが、深いCステートはウェイクアップパスを長くすることがある。Cステート、頻度、パケットレイテンシー、ジッターの遠隔測定によって、私は情報に基づいた決定を下すことができる。もしあなたがカーネルのメンテナンスも行うのであれば、いくつかの点でメリットがある。 カーネルの最適化, 私はそれを一貫してメンテナンス・ウィンドウに組み込んでいる。.

私は特にバーストシナリオ（短く集中的なフェーズ）をテストし、待ち時間のピークを周波数とCステートのトレースと相関させる。EPPを固定した測定がここで役に立つ。また、ウェイクアップレイテンシの割合を視覚化するために、Cステートを限定した短いテストもある。NO_HZ_FULLコアを使用する場合は、ハウスキーピングCPUの供給が不足しないようにします。.

セキュリティ：現在のカーネルは2回支払う

システム 現在, 新しいカーネルは省エネ経路を改良するだけでなく、ギャップを埋めることもできるからだ。カーネルの脆弱性に関する報告によると、攻撃者は時折、少しの努力で権利を拡張することができる。アップデートによって、このリスクを減らすと同時に、最新のメカニズムがもたらす効率性の向上を確保することができる[2]。全体として、運用上のセキュリティは向上し、計画外のダウンタイムが神経や予算に負担をかけることはない。まさにこのセキュリティと 効率性 定期的なアップデートを簡単に決断できる。.

データセンター効果：PUE、ファン、電源装置

目覚めの回数が減る 負荷 冷却と配電について測定することができる。CPUのピークがよりスムーズになり、ファンが限界に達する頻度が減り、電源装置がより効率的に働くようになる。このドミノ効果は、サイトのPUEに直接的な影響を与えます。さらに詳しくお知りになりたい方は、以下のトピックをご覧ください。 グリーンデータセンター そして、全体的なエネルギー管理システムの構成要素としてTicklessを使用している。ハードウェア、OS、ワークロードが一緒になって、エネルギー消費量に貢献するからです。 貯蓄 と。

WordPress、PHP、データベースの実践的トリミング

ショートスタックの多いCMSスタックでは お問い合わせ キャッシュレイヤーとクリーンなPHP-FPMのチューニングが大いに役立っている。opcacheを温存し、Chattyプラグインを封印し、タスクウィンドウを重ねることでcronのノイズを最小限に抑えています。データベースには明確なメンテナンス期間を設け、日々の負荷にI/Oピークを押し付けないようにしています。Ticklessを併用することで、バックグラウンドのノイズは減少し、サーバーはより早くアイドル状態になります。このようにして、このプラットフォームはワットあたりのパフォーマンスを向上させ、ユーザは以下のような問題が発生しません。 損失 ご覧ください。

具体的には、WordPressのcronトリガーを減らし、定期的な作業をsystemdタイマーに移し、合体させ、PHP FPMのワーカーを常時大量にオープンにしておくことなく、短い負荷の波に対応できるようなディメンションにしています。データベースは、明確な自動バキュームウィンドウ（必要なときにスロットル/移動）と一貫した「メンテナンスブロック」から恩恵を受ける。私は、定期的だがタイムクリティカルではないタスクは、秒単位で実行するのではなく、粗い粒度でバンドルすることを好む。.

BIOS/UEFIとハードウェアパス

私はすでにBIOS/UEFIで、深いパッケージのCステートを有効化し、ASPM/PCIe L1基板を使用し、全体的に省エネ機能を停止しない、という基本を設定しています。私は、特別なレイテンシターゲットが必要とする場合にのみ、テストベースでCステートの深さを制限しています。ネットワークカードとNVMeコントローラーは省電力モードの恩恵を受けますが、積極的な電源管理によってレイテンシのピークが発生していないかチェックします。最大限の節電でギアを1つ減らすと、99pのレイテンシ範囲に大きな影響を及ぼす可能性がある。.

ネットワークとストレージ：ウェイクアップをプッシュし続ける

ネットワークスタックは多くのIRQをトリガーすることが多い。私は、不必要にレイテンシを悪化させることなく、割り込みの嵐をスムーズにするために、合体パラメータを注意深く増やしている：

#の例（ワークロードに応じて値を調整しよう）
sudo ethtool -C eth0 rx-usecs 16 rx-frames 16 tx-usecs 16 tx-frames 16

GRO/LROとRSSをCPUトポロジーに合わせてスケーリングし、割り込みノイズの大部分を数コアで受け持つようにします。ストレージ側では、デバイスのプロパティ（NVMe-APSTなど）がすでに最適化されており、負荷ピークがバックグラウンドジョブ（スクラブやリビルド）のために日々のピークに及ばないかどうかをチェックする。目的は、計画可能なI/Oバーストを定義されたウィンドウに押し込むことだ。.

エラーパターンとトラブルシューティング

ティックレスのセットアップが基本的なメカニズムで失敗することはほとんどなく、むしろ微調整が原因で失敗することの方が多い：

  • RCUが失速NO_HZ_FULLが発生した場合、通常はハウスキーピングCPUが少なすぎるか、孤立コアのIRQ負荷が高すぎることが原因である。より多くのハウスキーピング能力を計画してください。.
  • 予期せぬ目覚めPowertopは犯人を示している。頻繁に発生する原因は、テレメトリーエージェント、短いタイマー間隔、またはチャットログです。.
  • 不均等なIRQ分布proc/interruptsをチェックし、アフィニティーを再調整し、irqbalanceを正しく設定する。.
  • レイテンシ・ジッターC-stateの深さ、EPPおよび合体度は徐々に変化し、p99を観察する。.

再現性のある結果を得るために、私は変更ウィンドウ、明確なロールバックポイント、正確に文書化されたパラメーターを使って作業する。各変更には測定ラウンドが与えられ、そこで初めて次のステップが実行される。.

具体的なステップ

まずは現在のところから カーネル そして、NO_HZ_IDLEがアクティブかどうかをチェックする。その後、アイドル時の消費電力、温度、Cステート、IRQレート、レイテンシーなどのベースラインを測定する。その後、ティックレス・オプションを有効にして測定を繰り返す。節約できることがわかれば、コードとドキュメントのレポにコンフィギュレーションを保存する。必要であれば、選択したコアのNO_HZ_FULLをテストし、IRQの割り当てに注意して、コアを分離する。 効果 が見える。.

私の現実的な手順

  1. ベースラインの収集（10～15分のアイドル＋短時間の負荷テスト、メトリクスの保存）
  2. NO_HZ_IDLEをチェックし、ハイレゾタイマーとアイドルドライバを検証する。
  3. IRQアフィニティとIRQバランスを調整し、ハウスキーピングでIRQを大音量にする。
  4. タイマーの合算を増やす (systemd timer, TimerSlack, cron intervals)
  5. オプション：選択したコアにNO_HZ_FULL + rcu_nocbs、少なくとも1-2個のハウスキーピングCPUを空ける。
  6. NUMAとCPUのピン留め、Cgroupの制限、バッチウィンドウの調整
  7. 決定前と決定後の比較、決定内容の文書化

私の簡単な要約

ティックレスがもたらすもの エネルギー- 特にアイドルフェーズの長い柔軟なワークロードでは、熱的な利点があります。私はNO_HZ_IDLEから始め、これを賢明な電力プロファイルと組み合わせます。その後、IRQアフィニティ、負荷バンドル、測定規律に取り組みます。特にレイテンシが重要なシナリオでは、NO_HZ_FULLを多用し、現実的なテストでトレードオフを評価する[1]。テクノロジー、ワークロード設計、モニタリングを組み合わせれば、次のようなことが可能です。 ポテンシャル このカーネル関数の永久的な.

現在の記事