コンテンツにスキップ 
レイテンシが重要なサーバーワークロード向けに、次のようにしてCPUコアを意図的に分離しています。 CPUの分離, 、これにより、スケジューラ、割り込み、および補助サービスがこれらのカーンに干渉しなくなる。そこで、次のようにして強制する。 isolcpus, nohz_full および rcu_nocbs は、リアルタイム処理、トレーディング、VoIP、クラウド RAN、あるいは要求の厳しいデータベーススレッド向けに、確定的な応答時間を提供します。.
中心点
明確なスタートを切るために、以下の核心となる考えをまとめます。 CPUの絶縁 これらをまとめ、実用的な観点から分類します。ジッターを低減し、レイテンシを再現可能にするため、システム・ハウスキーピングとクリティカルなスレッドを意図的に分離しています。 そのために、カーネルパラメータを設定し、アプリケーションのアフィニティを能動的に制御しています。メモリアクセスがレイテンシの原因となるため、NUMAとメモリの局所性にも常に注意を払っています。最後に結果を分析し、測定値から、どこをさらに最適化すべきか、どこで十分かを判断します。 リソース 自由であり続ける。.
- isolcpus 定義されたワークロード専用にコアを割り当てます。.
- nohz_full 分離されたコアにおけるティック割り込みを減らし、それによってジッターを低減します。.
- rcu_nocbs RCUコールバックをハウスキーピング用CPUに移行する。.
- 親和性 taskset/numactl を使用すると、スレッドを隔離されたコアに固定的にバインドできます。.
- NUMA また、IRQアフィニティにより、メモリパスと割り込みパスが整理されます。.
CPUの分離を理解する：カーネル、スケジューラ、アフィニティ
隔離がない場合、スケジューラはすべてのコアを共通の プール, スレッドを動的に割り当て、タスクを継続的に移行します。これによりスループットは向上しますが、応答時間にばらつきが生じます。そのため、予定外の処理が実行されないよう、このプールから特定のコアを除外しています。 アフィニティが設定されているプロセスだけがこれらのコアを使用でき、それ以外はすべてハウスキーピング用CPUに残ります。このようにして、ジッターを著しく低減し、応答曲線を平滑化する安定した処理環境を構築しています。.
実際の業務では、私は以下を組み合わせています isolcpus nohz_full と rcu_nocbs を使用して、カーネルの活動をさらに抑制しています。システムサービス、タイマー、cron ジョブが隔離されたカーネルに割り当てられないよう注意しています。 ハウスキーピングセットが運用負荷を担い、分離されたカーネルは計画可能な計算時間を提供します。この厳格な分離には、アフィニティ管理における規律が求められます。これを一度適切に実装すれば、レイテンシのピーク時に即座にその恩恵を受けられることがほとんどです。.
GRUBでisolcpusを設定する：手順解説
設定を行う前に、以下のコマンドで確認します。 lscpu トポロジー、SMTスレッド、NUMAノード。論理的な兄弟プロセッサが干渉しないよう、SMTパートナーを含めて、可能な限りコアをペアごとに分離します。その後、 /etc/default/grub カーネルのブート行を指定します。例えば： GRUB_CMDLINE_LINUX="isolcpus=4-7 nohz_full=4-7 rcu_nocbs=4-7". その後、GRUBの設定を書き換えます（アップデート・グラブ 或いは grub2-mkconfig) を実行し、サーバーを再起動します。起動後、以下のコマンドでアクティブなパラメータリストを確認します。 /proc/cmdline 或いは dmesg.
さらに、実行中のサービスのCPUアフィニティも確認し、隔離されたコアに意図しないものが現れないようにしています。systemdユニットとコンテナ定義ファイルは、明確に区別して管理しています。この区別が不十分だと、隔離されたコアがアイドル状態のままになったり、不要なタスクが混入したりしてしまいます。 どちらもパフォーマンスの低下を招くか、測定値を歪めてしまいます。システムへの変更によって隔離が知らぬ間に緩んでしまわないよう、割り当て内容を恒久的に記録しています。.
実行時間制御の手法：cpuset/cgroups、taskset、Tuna
ブートローダーを経由してすべての変更を行うのは避けたいので、実行時には cpuset-Cgroups、taskset、またはTuna。cpusetを使ってCPUグループを作成し、サービスに固定的に割り当てています。これは、多くの場合、systemd-Slicesやコンテナプラットフォームを通じてオーケストレーションされます。tasksetは、アフィニティを厳密に設定する明確な単一プロセスや短時間のテストに適しています。 Tunaは、IRQアフィニティやハウスキーピング用CPUを柔軟に調整するのに役立ちます。この多層的な戦略により、基盤は厳格に保たれつつ、日々の業務における微調整の余地も確保されています。.
サービスのライフサイクルに応じて判断します。継続的なサービスについては、 cgroups, 、taskset を使った短命なツールです。Kubernetes や Podman では、Pod をコアやノードに的を絞ってマッピングしています。 一貫した結果を得るために、サービスごとのルールを明確に定義し、アップデート後にその遵守状況を確認しています。これにより、基本コンセプトを損なうことなく、アーキテクチャの可追跡性と変更の柔軟性を維持できます。これを徹底して実践すれば、後々のトラブルシューティングにかかる時間を大幅に節約できます。.
割り込みとハウスキーピング用CPU：目立たない妨げ要因
クリーンなし IRQアフィニティ たった1つの割り込みが隔離されたコアに割り当てられると、レイテンシの予測がすべて台無しになってしまう。そのため、私はマスクを以下のように設定している。 /proc/irq/*/smp_affinity これにより、関連するすべてのIRQがハウスキーピングカーネル上に留まるようにします。カーネルスレッドやRCUコールバックについても、rcu_nocbsやチューニングツールを使用して、同様にそこに配置します。 ネットワークトラフィックやストレージI/Oなどの軽い負荷をかけてこれを検証し、分離されたカーネルを監視します。ハードウェア側の割り当てに関するより詳細な情報については、以下の簡潔なガイドを参照してください。 IRQアフィニティとマルチプロセッサシステム.
ハウスキーピングセットとして、システムサービス、タイマー、バックグラウンドタスクが滞らないよう、常に十分な数のコアを割り当てています。 セットの規模が小さすぎると処理の滞りが生じ、システム全体に悪影響を及ぼします。また、メンテナンスウィンドウ、バックアップ、デプロイメントのためのバッファも確保しています。隔離されたコアはこれらに影響を受けず、一貫した応答時間を維持します。この分離により、ピーク時の運用における予測可能性が高まります。.
NUMAを意識した分離とメモリの局所化
マルチソケットホストでは、以下の点に注意しています NUMA, 、リモートアクセスは不必要なレイテンシを発生させるためです。私はNUMAノードごとにコアを分離し、メモリを numactl --membind 同じノード上へ。隔離されたコア上のスレッドは、ローカルにRAMにアクセスするため、アクセス経路が短縮されます。CPUおよびメモリアフィニティについてより深く理解するために、私はこの短い論文をよく参照しています。 NUMAを意識したプロセスアフィニティ. ハードウェアを設計する際は、後の割り当てが容易になるよう、明確なトポロジーに留意する。.
さらに、ハイパースレッディングがどのように作用するかも検証しています。レイテンシが重要なタスクの中には、SMTパートナーを空けておくか、あるいはまとめて隔離することでパフォーマンスが向上するものもあります。これは、キャッシュプレッシャー、分岐ミス挙動、およびメモリアクセスパターンによって異なります。 私は対象を絞って測定を行い、ワークロードごとに判断を下します。一律のルールが役立つことはめったにありませんが、信頼性の高い測定データは極めて有用です。.
絶縁コアの選定とアプリケーションスピニング
まずは、厳選された少数のものから始めます コア 必要に応じてスケーリングを行います。アプリケーションのスレッドは、taskset、systemd-CPUAffinity、numactlなどを使用して、明示的に分離されたコアに割り当てます。アフィニティを厳密に設定しないと、分離されたコアは空き状態のままとなり、その効果は失われてしまいます。 この手法を客観的に評価するには、以下のコメントを参照することをお勧めします。 ホスティングにおけるCPUのピンニング. データに基づいて、どこで「ピニング」がレイテンシを低減できるか、どこで柔軟な分散の方が適切かを判断します。.
明確なスレッドアーキテクチャを持つワークロードは、特に大きな恩恵を受けます。固定のワーカーセットを持つデータベース、ホットスレッドの数が少ないインメモリキャッシュ、あるいはリアルタイムパイプラインなどは、この点で良好な結果をもたらします。 新しいサービスが誤って隔離されたコアに割り当てられないよう、割り当て状況を記録しています。サーバーを拡張する際は、レイアウトを調整して再度測定を行います。アフィニティ管理を厳格に行うことは、長期的に見て大きな成果をもたらします。.
モニタリングと反復的な調整
私は、その前と後のレイテンシ、ジッター、および負荷を測定しています。 断熱, 、そうでないと手探りの状態になってしまいます。perf、sar、トレーススタックといったツールは、傾向や外れ値を示してくれます。平均値だけでなくパーセンタイルを比較することで、スパイクを可視化しています。 その後、nohz_fullセット、rcu_nocbsセット、IRQマスク、ハウスキーピングセットのサイズといったパラメータを微調整します。実際の進捗を把握できるよう、変更のたびに測定ポイントを記録しています。.
私はチューニングのプロセスをシンプルにしています。仮説を立て、変更を加え、測定を行う。そうすることで、矛盾した結果を回避しています。 すべてのカーネルパラメータとサービスアフィニティを一元的に記録しています。アップデート後の監査を行うことで、デフォルト設定が最適化設定を上書きするのを防ぎます。このサイクルにより、迅速かつ信頼性の高い結果が得られます。.
リアルタイムスケジューリングを効果的に活用する
隔離は、私が スケジューリング方針 適切に選択する。厳密に時間制約のあるセクションには、SCHED_FIFO または SCHED_RR を設定し、慎重に調整して明確な上限を設ける。分離されたコア 4～5 上で動作する 2 スレッドのプロセスの例：
taskset -c 4-5 chrt -f 90 ./pipeline --threads=2
systemd を使えば、こうした設定を恒久的に定着させることができます。ユニットファイル内で、アフィニティとリアルタイム優先度を定義します：
[Service]
CPUAffinity=4 5
AllowedCPUs=4-5
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=90
NUMAPolicy=bind
NUMAMask=1
SCHED_FIFOスレッドがCPUを独占しないよう注意を払っています。RTセクションの割合が高すぎると、ハウスキーピング処理の速度が低下する恐れがあります。そのため、RTセクションを厳密に計画し、異常を検知してサービスを適切に再起動するウォッチドッグを用意しています。.
cgroup v2 と systemd：安定した割り当て
と一緒に cgroup v2 サービスをCPUセットに適切にバインドし、副負荷を調整します。. 許可されるCPU数 cpuset レベルで有効なコアを制限し、, CPUアフィニティ タスクのアフィニティを設定します。さらに、バックグラウンドサービスがパフォーマンスのピーク状態にならないよう、CPUWeight/CPUQuota を使って調整しています。再現性のあるデプロイを行うために、スライスを定義しています（例： system.slice 対 realtime.slice) および適切なサービスを割り当てます。同じスライス内でコンテナを起動する限り、コンテナはこれらのルールを確実に継承します。.
電力管理、周波数、およびCステート
強い 遅延ピーク これらは多くの場合、省電力機構に起因します。私は絶縁されたコアにパフォーマンス・ガバナーを設定しています：
cpupower frequency-set -g performance
バースト性能よりも決定論的な実行時間が重要である場合は、必要に応じてTurboを無効にします：
echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo
厳しいリアルタイム目標がある場合、私は深い睡眠状態（C-States）を、例えば次のような方法で削減します。 intel_idle.max_cstate=1 あるいは極端なケースでは idle=poll カーネルのコマンドラインで。これによりウェイクアップの遅延は短縮されますが、消費電力と発熱量は増加します。私はこれらの設定を意図的に適用し、広範囲に展開する前にジッターへの影響を測定しています。.
メモリ：Huge Pages、THP、および事前割り当て
多くのレイテンシーのピークは、以下の要因によって生じます。 メモリページ-管理。ワークロードに大規模で長寿命のヒープが含まれる場合、静的なHuge Pagesを使用しています：
echo 512 > /proc/sys/vm/nr_hugepages
Transparent Huge Pages（THP）は、デフラグ処理によってジッターを引き起こす可能性があります。ハードリアルタイム環境では、私はよくTHPを次のように設定しています。 決して:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
また、メモリを事前にウォームアップ（タッチアロケーション）し、アプリケーションで指定されている場合はピン留めも行います。NUMAバインディングと組み合わせることで、実行時のページフォールトが減少し、応答時間が安定します。.
仮想化とコンテナ：すべてのレイヤーにわたるピンニング
時点では バーチャル 環境設定においては、一貫して隔離を徹底しています。ホスト上では `isolcpus/nohz_full` を使用して pCPU を予約し、ハイパーバイザー上では VM の vCPU をこれらの pCPU に厳密に固定し、エミュレータスレッドと I/O スレッドをハウスキーピング用コアに移します。 KVMでは、vCPUおよびエミュレータのピンニングにvirshコマンドを使用し、QEMUでは、iothreadsにハウスキーピングゾーン内の専用コアを割り当てています。これにより、I/Oのピークが分離された計算コアに影響を与えるのを防いでいます。.
コンテナ内では、cpusetを明示的に定義しています（--cpuset-cpus) そして、以下の条件を満たすようにしてください。 保証-ワークロード（固定のCPUおよびメモリ制限）が、分離されたコアに割り当てられます。静的モードのKubelet CPUマネージャーは、そのようなPodに実際のCPUスライスを割り当てます。 重要：IRQおよびホストのハウスキーピングは引き続き隔離ゾーンの外に留めておく必要があります。そうしないと、問題が単に別の場所に移るだけになります。.
典型的な妨害要因を特定し、その影響を和らげる
私は定期的に、以下の点を確認しています。 イラクバランス 手動で設定したIRQマスクを上書きしてしまいます。静的な割り当てが優先される場合は、適切に設定するか、あるいは無効にする必要があります。私は次のような現象を確認しています ksoftirqd-負荷のピーク：これは、ネットワークカードのRX/TXキューが適切に分散されていないことを示唆することがよくあります。 私はハウスキーピング用コアごとにキューを分割し、分離されたコアを確実に空き状態に保っています。また、バックグラウンドスキャナ、インデックス作成、ログローテーションのジョブについても、リアルタイムパスに一切影響を与えないよう、厳格にハウスキーピングゾーンに割り当てています。.
断定的な主張に対する検証方法
のために ジッター 私は、cyclictest のような合成テストや、taskset を使って分離されたコアに割り当てる、短くて再現性のあるマイクロベンチマークを利用しています。 perfとトレーススタックを用いて、異常値がコンテキストスイッチ、IRQ、ページフォールト、あるいは周波数変更と相関しているかどうかを分析します。 測定は常にパーセンタイル（p99/p99.9）で行い、単純な平均値で真実を歪めることはありません。ネットワークパスについては、IRQおよびNAPIの負荷がハウスキーピングドメインに適切に流れていることを検証します。.
ブループリント：16スレッドのホストでの保守的な開始
まずは実用的な観点から始めたいと思います。4つのスレッド（2つの物理コアとSMTパートナーを含む）を分離し、残りはハウスキーピングに割り当てます。例を挙げると： isolcpus=8-11 nohz_full=8-11 rcu_nocbs=8-11 irqaffinity=0-7,12-15 （IDは例示です）。重要なサービスのPINを厳密に8～11に設定し、パフォーマンス・ガバナーに切り替え、THPを無効化し、numactlでRAMをローカルにバインドし、IRQマスクを確認します。 p99が安定して低下してから初めて、隔離範囲を拡大します。このようにして、リスクと手間を最小限に抑えつつ、レイテンシを確定的に改善しています。.
パラメータリファレンス：isolcpus、nohz_full、rcu_nocbs
日常生活では、コンパクトなものが重宝しています 概要 最も重要なカーネルパラメータです。私はこれらを、デプロイ前のチェックリストやトラブルシューティングの際に活用しています。例はカーネル4～7に適用されますが、他のバージョンにも応用可能です。ハウスキーピング用のカーネルが十分に確保されるよう注意しています。隔離設定を過度に厳しくしすぎると、システムサービスにボトルネックが生じる恐れがあるからです。.
| パラメータ | 効果 | 典型的な例 | ヒント |
|---|---|---|---|
| isolcpus | グローバルからカーネルを削除します スケジューリング-プール | isolcpus=4-7 | ワークロードごとにアフィニティ設定が必要 |
| nohz_full | ティックレス動作による低消費電力 ジッター | nohz_full=4-7 | 特にシングルタスクの状況で効果を発揮する |
| rcu_nocbs | RCUコールバックをハウスキーピング用CPUに移行する | rcu_nocbs=4-7 | Isolates でのカーネルの動作を軽減します |
| irqaffinity | デフォルトのIRQターゲットカーネルを ボート | irqaffinity=0-3 | 手動マスクと併せて、ベースラインとして有用 |
| rcu_nocb_poll | RCUのウェイクアップ動作を変更する | rcu_nocb_poll | 必要に応じて、負荷プロファイルに応じてテストを行う |
アクティブなパラメータ設定を、一元化された ランブック. これには、カーネルのコマンドライン、IRQマスク、systemdのCPUアフィニティ、およびNUMAバインディングが含まれます。 大規模なシステムでは、再現性を確保するために「Infrastructure-as-Code」も有効です。これにより、次回のメンテナンスサイクルで設定がすべて元に戻ってしまうことを防ぎます。再現性のある設定は、あらゆるトラブルシューティングを迅速化します。.
ホスティングの設定とプロバイダーの選択
真の自由を手に入れるために カーネル-パラメータに関しては、ブートローダーとハードウェアのトポロジーを完全に制御できる必要があります。明確なNUMA構造と十分な物理コアを備えた専用サーバーなら、そのための余裕が得られます。 ホスティングサービスとの比較において、webhoster.deはハードウェア性能と設定の自由度を優先しているため、しばしば合理的な選択肢と見なされています。 事前に、isolcpus、nohz_full、rcu_nocbs を問題なく設定できるかどうかを確認します。その後、分離を段階的に展開し、各ステージごとにその効果を測定します。.
測定結果の比較可能性を維持できるよう、アップデート、カーネルの変更、ファームウェアの調整を計画しています。 どのような変更でもレイテンシ曲線をずらす可能性があります。また、ネットワークカード、IRQの割り当て、ストレージキューについても考慮しています。これらすべての要素が結果に影響を与えます。セットアップを綿密に計画すれば、予測可能なパフォーマンスを得ることができます。.
リスク、障害、および再発時の対応策
種をたくさん食べると 絶縁, 、システムのハウスキーピングに悪影響を及ぼし、新たなボトルネックを生み出します。アフィニティを設定しないと、孤立したコアは未使用のままとなり、効果はゼロになります。 IRQアフィニティの設定が不適切だと、特定が困難な断続的なレイテンシの急上昇を引き起こします。モニタリングが行われていないと、原因と結果が不明瞭になってしまいます。そのため、私は常に文書化された「元に戻す手順」を用意しています。パラメータを元に戻し、正常に再起動し、測定値を比較した上で、段階的に再構築していくのです。.
私は、ピーク時に導入する前に、閑散期に各構成をテストしています。そうすることで、リスクを早期に発見できるからです。また、バックアップジョブ、ログ処理、セキュリティスキャナーへの影響についても確認しています。これらのタスクは、隔離されたコア上で実行されてはならず、独自のリソースを必要とするからです。 明確な復旧計画を立てておくことで、長引く障害を防ぐことができます。.
実施のためのチェックリスト
まずはトポロジー解析から始め、 コア-SMTパートナーを含むペア；GRUBでisolcpus/nohz_full/rcu_nocbsを設定して再起動；/proc/cmdlineとdmesgを用いてパラメータ設定が有効であることを確認；ハウスキーピング用CPUとIRQマスクを設定； taskset、systemd、またはcgroupsを使用して重要なスレッドをピン留めします。numactlを用いてメモリを適切なNUMAノードにバインドします。変更の前後でレイテンシとジッターを測定します。すべてをランブックに記録し、フォールバック手順を用意しておきます。 このプロセスは管理しやすく、再現性があります。これにより、混乱を招くことなく、少数のコアから多数の分離されたコアへとスケールアップできます。最終的に重要なのは、応答時間に対する測定可能な効果です。私はまさにこの点をもって、各変更の成功を評価しています。.
簡単にまとめると
以下で予約します isolcpus 専用コアを活用し、割り込みを排除し、重要なスレッドを的確にピン留めします。これにより、ジッターを低減し、応答時間を安定させ、ハウスキーピングとワークロードを明確に分離した環境を構築します。NUMAバインディングとIRQアフィニティにより、データ転送経路を短縮します。 モニタリングと、小さく追跡可能な手順を踏むことで、信頼性の高い結果が得られます。明確なドキュメントを作成することで、セットアップの保守性を維持し、1マイクロ秒が重要な場面でも再現性のあるパフォーマンスを実現します。.
