サーバーと仮想マシン

LinuxでのIRQバランスの正しい設定方法：実践ガイド

Linuxにおいて、IRQ Balanceはハードウェア割り込みのCPUコアへの割り当てを制御し、ネットワーク負荷が均等に分散されるか、あるいは個々のコアの処理速度が低下するかを決定します。ここでは、irqbalanceを効果的に活用する方法、手動によるIRQアフィニティへの切り替えのタイミング、そして高負荷のサーバーにおける適切な設定について解説します。 ネットワーク負荷 本当に重要なこと。.

中心点

詳細に入る前に、I/O負荷の高いプロジェクトにおいて、私にとって確実に役立った重要な判断をまとめておきます。 irqbalanceによる自動割り当てを起点として、その効果を測定し、必要に応じて選択的に調整するのが有効だと考えています。決定論的なワークロードの場合、個々のIRQを特定のコアに手動で割り当て、残りのCPUを自動割り当ての対象から除外します。 NUMA近接性は、レイテンシを低減し、スループットを確保するため、早い段階から考慮に入れます。明確なモニタリングにより、ボトルネックを迅速に特定し、不必要な リスク.

このリストは、私が設定の際に特に注意している点をまとめたものです：

自動まず：irqbalance を有効にし、その効果を測定する
親和性 的を絞って：重要なIRQをピン留めし、ジッターを低減する
使用禁止のCPU: アプリスレッド用にコアを確保する
NUMA 注意：IRQはメモリノードの近くに配置すること
モニタリング: /proc/interrupts およびレイテンシを確認する

IRQの基礎を簡単に解説

割り込み要求（IRQ）とは、ハードウェアが処理をCPUに引き渡し、それによって実行中のタスクを中断させる信号のことです。これらの信号が同じコアに過剰に集中すると、そのコアの負荷が高まり、応答時間が遅くなる一方で、他のコアは遊休状態のままになってしまいます。まさにこの問題を解決するために、私は流通回避する。irqbalance はこれらの IRQ を複数のコアに動的に割り当て、一定間隔でシステムの状態を評価します。まず、これについて /proc/interrupts を確認し、各列からCPUごとにどれだけのIRQが到着しているかを把握します。特定の列の値が過剰になった場合は、積極的に調整を行い、不要な ホットスポット.

irqbalance による自動分散

最新のディストリビューションでは、デフォルトで定期的にIRQの割り当てを調整する「irqbalance」サービスで起動します。これを有効にするには、 systemctl enable --now irqbalance そして、さらに深く手を加える前にステータスを確認します。そうすることで、既存のものを活用しています。自動. 設定ファイルは、システムによって異なるが、 /etc/sysconfig/irqbalance 或いは /etc/default/irqbalance, 、そこでCPUやIRQを除外することができます。特に役立つのが、この変数です IRQBALANCE_BANNED_CPUS 64ビットマスクとして、アプリケーション用に定義されたコアを予約するために使用されます。実践例についてさらに詳しく知りたい方は、こちらの簡潔な入門記事をご覧ください。ネットワークのパフォーマンス, 、これは私がワークショップで頻繁に参照し、プロジェクトでも採用しているものです。.

IRQアフィニティを手動で確実に設定する

ワークロードがジッターに非常に敏感である場合や、特定のコアをユーザースペースプロセス専用に確保しておく必要がある場合は、IRQアフィニティを手動で設定します。その際、ビットマスクを次のように記述します。 /proc/irq/IRQ番号/smp_affinity そして、どのカーネルで割り込みを実行できるかを指定します。これにより、計画的な運用が可能になります。行動. まず、以下のコマンドで関連するIRQ番号を確認します。 グレップ に於いて /proc/interrupts. ネットワークデバイスについては、RX/TXキューをアプリスレッドに近いコアに割り当てる一方で、他のコアは空き状態にしておくことがよくあります。この手法に関する詳しい背景については、この短い記事にまとめられています。 IRQアフィニティガイド, 、私が定期的に出発点として利用している場所です。.

次の表は、一般的なビットマスクとその意味を示しています。私はこれらの例を活用して、設定を迅速かつミスを少なく行い、その後、 /proc/interrupts にとって 検証する.

ゴール	サンプルマスク（16進数）	カーン	コメント
CPU0のみ	0x1	0	簡単なテスト、低散乱
CPU1のみ	0x2	1	CPU0からIRQを切り離し、干渉
CPU0～CPU1	0x3	0–1	2つのコアに分散され、軽量な救済
CPU2–CPU3	0xC	2-3	アプリスレッドで 0–1 の場合に便利無料滞在
CPU0～CPU3	0xF	0–3	4つのコアに広く分散し、混合する負荷

測定：/proc/interrupts を正しく読み取る

ファイルを開きます /proc/interrupts すると、行ごとに1つのIRQ、列ごとに各CPUのカウンタが表示され、これにより不均衡がすぐにわかります 目に見える. あるカラムが他のカラムよりも明らかに急速に増加している場合、そこに負荷が集中します。その際は、どのドライバが関与しているか、またRSS/RPSがすでに分散されているかを確認します。さらに、irqbalanceを一時的にフォアグラウンドでデバッグ出力を有効にして実行し、その判断プロセスを理解して誤った判断を避けるようにしています。変更のたびに、カウンタを再確認し、負荷がかかった状態でのレイテンシを測定して、その影響を裏付け、不必要な リスク 避けることができる。.

CPUの分離と禁止マスク

をセットした。 IRQBALANCE_BANNED_CPUS, 、特定のコアを自動割り当てから一貫して除外するためです。これにより、アプリスレッド用のリソースを確保しています。新しい環境では、さらに IRQBALANCE_BANNED_IRQS, 、個々のデバイスを1つのコア上で独立して動作させる必要がある場合；これにより、敏感なシステムへの干渉が軽減される ワークロード. 低レイテンシのシナリオでは、再割り当てによる干渉を防ぐため、意図的に irqbalance を無効にし、IRQ を静的に固定しています。割り込み処理の CPU 割り当てについてより詳しく理解したい方には、以下のリンクに役立つ背景情報が掲載されています。割り込み処理サーバー上で。重要なのは、まず測定し、次に設定を決定し、その効果を再度確認することで、予期せぬ事態を オペレーション を避けなければならない。

NUMAの側面と近接性

NUMAシステムでは、IRQを可能な限り、対象となるデータが格納されているメモリを持つNUMAノードのコアに割り当てるよう心がけています。これにより、レイテンシが低減され、 スループット. これとアプリケーションのCPUアフィニティを組み合わせることで、スレッドと割り込みが互いにローカルで動作するようにしています。irqbalanceはNUMA環境でも問題なく動作しますが、必要に応じてバンデッドマスクを使って微調整を行っています。重要なのは、負荷をローカルに保持できる場合は、ノード間で負荷を分散させないことです。この近接性を維持することで、安定した応答時間を確保し、貴重なリソースを節約できます。 キャッシュ-リソース。.

ネットワーク集中講座：RSS、RPS/RFS、XPS

IRQマスクを微調整する前に、RSSなどのNIC機能や、RPS/RFS、XPSといったカーネルメカニズムを確認します。これらはパケットの分散に大きな影響を与えるからです。 RSSはすでにキュー割り込みを複数のコアに分散させており、RPS/RFSはカーネル内での処理を、XPSは送信経路を形成します。これにより、不要な ホットスポット. これらのメカニズムが互いに干渉しないように、私のIRQ戦略に合わせて調整しています。キュー、IRQアフィニティ、およびアプリアフィニティが適切に調整されていれば、ネットワークI/Oは格段にスムーズに動作します。その後、実際の負荷下で再度測定を行い、さらに ステップ を置く。.

MSI-X、マルチキュー、および整然としたキューのレイアウト

多くの10～100G NICはMSI-Xを採用しており、RX/TXキューごとに独自の割り込みベクタを用意しています。まず、次のように確認します。 ethtool -l eth0 （チャンネル数）および /proc/interrupts, 、実際にアクティブなキューがいくつあり、その名称は何か（例：. eth0-TxRx-0, eth0-TxRx-1). 目的は、キューの数をNUMAノードごとに使用されているコア数に合わせて調整し、それらを決定論的に固定することです。 ethtool -L eth0 combined N キューの数を設定し、その後、生成されるIRQを smp_affinity 適切なコアに割り当てる。同じキューのRX/TXペアを、同じコア、あるいは少なくとも同じソケットに配置するように注意している。そうすることで、 キャッシュの局所性 が適用されます。重要：キュー数とアフィニティの変更については、私は直接 /proc/interrupts そして、さらなる最適化を進める前に、簡単な負荷テスト（pps/スループット）を実施します。.

割り込みのコアレセンスとNAPIバジェット

特にパケットレートが高い場合、コアレッセンス値は私のIRQ戦略の有効性に影響を与えます。 ethtool -c eth0 ～かどうかがわかる rx-usecs そして rx-frames 設定されています。コアレセンスを増やすと、1秒あたりのIRQ数が減り、CPU負荷が軽減されますが、レイテンシとジッターが増加します。私は慎重に調整を行っています：少しずつ変更を加え、その都度測定（p95/p99レイテンシとCPU負荷）を行っています。送信側では、 tx-usecs 同様に。また、NAPIの挙動を以下のようにスケーリングしています。 net.core.netdev_budget そして net.core.netdev_budget_usecs, いつ NET_RX SoftIRQに蓄積し始める。ドロップが増加すると /proc/net/softnet_stat, 、試しに予算を増やしたり、RXキューをより一貫して割り当てたりします。システムのレイテンシが問題になる場合は、元に戻します。 GRO/LROとTSO/GSOについては、相互の関係を考慮に入れています。集約を過度に行うとIRQ負荷は低下しますが、レイテンシのピークが発生する可能性があります。そのため、アプリケーションのプロファイルに合わせて調整しています。.

SoftIRQを透過的に読み取る

ハードIRQに加えて、ソフトIRQの負荷についても私が決定します。 cat /proc/softirqs 私は観察する NET_RX そして NET_TX CPUあたり；特定の列が突出していると、ksoftirqdスレッドに過度な負荷がかかる。1つの top -H どれが該当するか、すぐに教えて ksoftirqd/N 種が重荷になる。もっと深く測ってみる perf top あるいは短い パーレコード ドライバやスタック処理内のホットスポットを確認するために実行します。 ksoftirqdスレッドがアクティブになると（IRQコンテキストでの即時処理の代わりに）、レイテンシが大幅に増加することがよくあります。その場合は、キューの分散を改善したり、NAPIバジェットを増やしたり、あるいは影響を受けるksoftirqdスレッドに対して以下のようにCPUピンニングを適用したりして対応しています。 taskset -pc. 重要：これらの調整は、その影響が微妙であるため、万が一の際には素早く元に戻せるよう、記録に残しています。.

SMT／ハイパースレッディングとトポロジーを正しく活用する

SMTが有効な状態では、1つの物理コアを2つの論理CPUと共有しています。以下の方法で、それらの兄弟関係を確認しています。 lscpu -e そして /sys/devices/system/cpu/cpuX/topology/thread_siblings_list. レイテンシが重要なパスについては、アプリスレッドとそれに関連するIRQを同じ物理コア（異なるSMTスレッド）に配置することを避けています。これらは実行ユニットやキャッシュを競合してしまうからです。例えば、アプリスレッドをCPU2で実行し、それに対応するRXキューをCPU3（別の物理コア、同じNUMAノード）で実行するような組み合わせを好んで採用しています。 SMTによって一貫性が損なわれる場合は、代わりに物理コア数を減らして排他的に割り当てることで、不安定な状況を回避しています。干渉.

仮想化：KVM、vhost、SR-IOV

仮想化環境では、ホストとゲストを別々に扱っています。ホスト上では、物理NICのIRQを、対応するNUMAノードの各コアに適切に分散させています。ゲストがvirtio-netを使用する場合、vhostスレッド用に追加のIRQが発生しますが、私はそれらを /proc/interrupts また、vhostワーカーを物理NICのキューと一貫性を持たせてピン留めします。ゲストレベルでも、virtioドライバが複数のキューを提供している場合は、RSS/XPSおよびIRQアフィニティを設定します。 SR-IOV を使用する場合は、各ゲストに独自の MSI-X ベクトルを持つ 1 つ以上の VF を割り当て、ゲスト内でそれらをピン留めすることをお勧めします。これにより、分離性が向上し、レイテンシと予測可能性が改善されます。私は明確なスキームに従っています。ゲストのvCPUを専用のpCPUに割り当て、関連するIRQを近くのコアに割り当て、エミュレータ／vhostスレッドを計算負荷の高いアプリスレッドと混在させない――そうすることで、データパスが 計画的.

CPU周波数、Cステート、およびNOHZチューニング

IRQのレイテンシは、コアが深いCステートに突入したり、積極的なクロック制御が行われたりすると悪影響を受けます。影響を受けやすいワークロードの場合、私はCPUガバナーを 演技 (cpupower frequency‑set -g performance) そして、起動オプションやドライバオプションを使用して深い C ステートを削減し、復帰時間を抑えます。負荷の高いサーバーでは、これはアフィニティの微調整を行うよりも、多くの場合、より良い効果をもたらします。レイテンシが非常に厳しい環境では、私は次のように追加しています nohz_full= そして rcu_nocbs= 分離されたコアに対して、ティックタイマーとRCUコールバックが干渉しないようにするためです。ハウスキーピング用CPUについては、意図的に別々に定義しています。ただし、これらの変更はスケジューリングや消費電力に副作用を及ぼす可能性があるため、個別にテストを行っています。重要なのは、変更前後の測定値を正確に比較することです。そうしなければ、 最適化 暗闇の中で。.

Systemd、Cgroups、およびアプリの分離

IRQのピンニングに加え、Cgroupsとsystemdのアフィニティを使ってアプリスレッドを分離しています。以下の方法を通じて CPUAffinity= UnitファイルやCPUコントローラー（cgroup v2）では、サービスに特定のコアを割り当てています。これにより、スケジューラ側で、IRQ用に割り当てたCPUにスレッドが割り当てられるのを防いでいます。コンテナ環境では、 cpuset.cpus と確認する。 cpuset.cpus.effective, 、リソースの約束が確実に実行されるようにするためです。重要： IRQBALANCE_BANNED_CPUS irqbalance が割り当てを行わない箇所のみを制御します。ksoftirqd などのカーネルスレッドは、引き続きスケジューラに従います。したがって、完全な分離を実現するには、IRQアフィニティ、サービスのCPUアフィニティ、そして必要に応じて分離されたカーネルを組み合わせる必要があります。これにより、データパスとアプリケーションが明確に分離され、負荷無秩序に混ざり合うことはない。.

よくあるミスと対策

負荷状況を把握せずに、irqbalanceを一律に無効にすることは決してありません。そうしないと、IRQがすぐに少数のコアに集中してしまうからです。同様に、敏感なスレッドが排他的なアクセスを行うにもかかわらず、すべてのIRQに対してすべてのコアを開放することも好ましくありません。 リソース が必要だ。もう一つの間違いは、変更を個別にテストせず、その影響を測定しないことだ。そうすると、何が実際に役立つのかが不明確なままになってしまう。また、ハイパースレッディングのペアについても考慮している。アプリスレッドとそれに対応するIRQは、同じ物理コアを共有しない方がよい。各ステップを記録し、ロールバックポイントを設定することで、問題が発生した際に迅速に最後の状態に戻れるようにしています。良い設定画面に戻ります。.

サーバーの実務チェックリスト

私は常にベースラインから始めます。irqbalanceを有効にし、システム負荷を計測し、/proc/interruptsを監視してレイテンシを測定します。その後に初めて設定を変更します。2番目のステップでは、次のようにして終了します。 IRQBALANCE_BANNED_CPUS アプリスレッド用に確保しておくべきコアを選択し、不要なIRQの割り込みを防ぐ。その後、重要なIRQを smp_affinity 厳選された少数のコアに絞り込み、NUMAの近接性を確保します。次に、RSS/RPS/RFSおよびXPS、ならびにNICのオフロードオプションを確認し、負荷を適切に分散させます。最後に、本番環境の負荷下でテストを行い、メトリクスを比較し、実証された効果のある変更のみを採用します。仕事.

設定ファイルと systemd コマンド

以下のコマンドでサービスを有効にします systemctl enable --now irqbalance そして、以下で確認してください systemctl status irqbalance 期間；そこで、私はこれを サービス 準備は万全だ。In /etc/sysconfig/irqbalance 或いは /etc/default/irqbalance 私は IRQBALANCE_BANNED_CPUS およびオプションとして IRQBALANCE_BANNED_IRQS. 変更は以下のように反映します systemctl restart irqbalance そして、同時に以下のカウンターを監視し、 /proc/interrupts. テストの際は、irqbalanceのフォアグラウンドモードを使用して、処理の経過をリアルタイムで追跡しています。その挙動を理解してから初めて、調整内容を恒久的に構成.

irqbalance を無効にする場合

リアルタイム環境や、レイテンシに極めて敏感なアプリケーションでは、再割り当てによる干渉を防ぐため、irqbalanceを停止し、IRQを静的に固定しています。これらのワークロード用にコアを分離し、トラフィック関連のIRQは意図的に他のコアで実行するようにしています。これにより、アプリケーションスレッドは 計画的. テナント環境が厳格に分離されている場合でも、VMやコンテナ間の干渉を軽減できるため、このアプローチは有効です。自動調整機能との相性が悪いドライバーが見つかった場合は、禁止リストを通じてそのIRQを除外します。負荷パターンが再び変動しやすくなったら、irqbalanceを再度有効にし、新しい 測定値.

簡単にまとめると

irqbalance を実行して効果を測定し、やみくもにあらゆる場所に手を加えるのではなく、選択的に調整を行います。そうすることで、システム全体の視点を維持し、 透明性. 敏感なワークロードに対しては、適切なIRQを割り当て、アプリケーションごとにカーネルを分離し、NUMAの近接性を考慮します。バンデッドマスクを使用して、irqbalanceが動作できる範囲を制御し、意図しない移動を防ぎます。定期的に確認しています /proc/interrupts, 、レイテンシ、スループットを測定し、変更の効果を確かな根拠に基づいて立証できるようにします。このように進めることで、IRQ Balanceの潜在能力を最大限に引き出し、ネットワーク負荷がかかっている状況でもサーバーのパフォーマンスを著しく維持することができます 反応性.