コンテンツにスキップ 
私がどのようにしているかを、順を追って説明します。 LinuxのSoftIRQ- 負荷を測定し、ボトルネックを可視化し、カーネルの設定をわずかに調整するだけで状況を再びコントロールできるようにする。その際、測定可能な効果を優先する：短縮された 遅延時間, 、CPUコアの負荷バランスが良好で、ネットワーク負荷が高い状況下でも安定したパケット処理が可能。.
中心点
- 測定ポイント 理解する：/proc/softirqs、softnet_stat、interrupts
- 症状 検知：ksoftirqdの負荷、パケット損失、遅延の急増
- チューニング 制御：netdev_budget および netdev_budget_usecs
- 流通 保存：IRQアフィニティ、RSS、キューマッピング
- モニタリング 実行するコマンド：mpstat、perf、トレース
SoftIRQの概要：カーネルの仕組み
ハードウェア割り込みが発生した後、カーネルは処理の一部をいわゆる ソフトIRQ, 、これによりクリティカルパスが速やかに解放され、処理の進行を計画通りに進められるようになる。特にネットワークパスにおいては、NAPIハンドラがNICリングからパケットを収集し、プロトコル処理を開始して、データを ネットワークスタック. イベントの発生量が増加すると、ksoftirqd/cpuN のような CPU スレッドが介入し、ポーリングや後処理を引き受けます。この分離により全体的なスループットは向上しますが、過負荷時には個々の CPU におけるソフト IRQ の実行時間が長くなる可能性があります。 コア を引き起こす。そのため、NET_RXおよびNET_TXパスが支配的になっていないか、またksoftirqdが明らかにCPU時間を消費していないかを早期に監視している。そうすることで、SoftIRQがボトルネックとなっているタイミングを把握し、さらなる 最適化 が必要である。
SoftIRQの負荷が高い場合の典型的な症状を見分ける
SoftIRQの負荷が高いことは、まず、常に高い カーネルCPU そして、数秒にわたってピーク値を維持し続けるksoftirqdプロセス。これと並行して、ネットワークおよびブロックI/Oのレイテンシが増加し、その結果、TLSハンドシェイクが重くなったり、処理が鈍くなったりする API と述べている。パケットの損失が頻発する一方で、ネットワークカードのリングはオーバーフローし、バックログが増大することが多い。割り込みの分散が不十分な場合、多くのIRQラインとそれに伴う処理が1つの コア 発生する。この単一コアのボトルネックにより、サービスの待ち時間が長くなり、実効スループットが低下する。そこで、この現象が体系的なものなのか、それとも単に ピーク につながる。.
主要な測定ポイント：/proc とツールの正しい読み方
まずは /proc/softirqs から始めよう。そこには、CPU ごと、タイプごとに、どの程度の負荷がかかっているかがわかるからだ。 NET_RX, NET_TX、TIMER、またはBLOCKが上昇する。/proc/net/softnet_stat では、予算超過やドロップを示唆するフィールドに焦点を当てて行を確認している。これらが継続的に上昇している場合、明らかに帯域幅が不足していることを示している。 ポーリングサイクル ことを示唆している。/proc/interrupts を確認することで、ハードウェア割り込みが各 CPU に不均等に割り当てられているかどうか、またどの IRQ が最も負荷が高いかがわかる。mpstat、top、htop などのツールを使えば、ksoftirqd/cpuN を特定し、その Softirqのタイミング コアごとに評価する。必要に応じて、perfはスタック内のホットスポットを特定し、処理時間の割合が高いハンドラやドライバパスを特定できるようにする。以下の表は、主要な測定ポイント、指標、および典型的な 行動 一緒にね。
| 測定ポイント | 主要な項目／指標 | 解釈 | アクション |
|---|---|---|---|
| /proc/softirqs | NET_RX、NET_TX、BLOCK それぞれ CPU | 荷重の偏りが確認できる | IRQアフィニティの調整、RSSの有効化 |
| /proc/net/softnet_stat | 予算／ドロップカウンター、第3 列 | 予算が少なすぎて、荷物が放置されたまま | netdev_budget/usecs を増やし、RPS を確認する |
| /proc/interrupts | IRQ-Lines pro CPU, キューマッピング | 少ないコア数に対してIRQが多すぎる | irqbalance の確認、smp_affinity の設定 |
| mpstat / perf | %soft、ホットスポット、, スタックス | 支配的なハンドラーとコアが表示される | ドライバとスタックのチューニングを優先する |
高負荷の原因とパターン
ピークは、非常に高い スループット, 、多数の並列接続や、NET_RXを支配するUDPバーストなど。ドライバのデフォルト設定では小さなバッチが想定されている場合があり、その結果、割り込みが過剰に発生してksoftirqdに過負荷がかかる一方で、GRO/LROは活用されないまま 残骸. 好ましくないアフィニティ設定により、利用可能なキューが複数あるにもかかわらず、処理がCPU 0に集中してしまい、RSSを活用すれば負荷分散が容易になるはずなのに。仮想マシンでは、vNICがホストカーネルに負荷をかけ、その結果、ゲストの犠牲を伴いながらホスト側のSoftIRQ時間が長くなってしまう 増加させる. コンテナオーバーレイはスタックに追加のパッケージを重ねるため、単純なフローが突然、より複雑なパスになってしまう。分散、予算、そして バッチ処理 全体としてまとまった印象を与える。.
的を絞った監視：SoftIRQの可視化
信頼性の高いモニタリングを行うために、私は定期的に以下の資料を読んでいます。 /proc-インターフェースを特定し、負荷やスケジューリング遅延といったホストメトリクスと関連付けます。NET_RXの増加とドロップカウントを相関分析し、単にスループットが増加しているだけなのか、それとも経路上でパケットが失われているのかを明らかにします 滞在. mpstat は CPU ごとにソフト IRQ の時間割合を表示し、top/htop は目立つ ksoftirqd/cpuN スレッドを表示します。perf record/perf top を使って、チェックサムのオフロードや GRO のマージなど、コストのかかる処理パスを特定します。 キューディスク-作業。eBPF や ftrace に基づくトレースでは、ハンドラの開始と終了が確認できるため、ハンドラの実行時間やスケジューリングの影響を評価することができます。これにより、メトリクスや時間経過、および ホットスポット.
netdev_budget および netdev_budget_usecs を使用したチューニング
NAPIパスが短すぎる場合は、段階的に延長します net.core.netdev_budget および net.core.netdev_budget_usecs を調整して、ポーリングサイクルあたりの処理パケット数を増やします。その際、/proc/net/softnet_stat の 3 列目を確認します。増加率が低下すれば、変更が的を射ており、レイテンシが より短い. 値を適度に増やしていきます。例えば、300 パケットから 600 パケットへ、2000 マイクロ秒から 4000 マイクロ秒へと変更し、他のタスクが十分な CPU 時間を確保できているかを確認します。 値が大きすぎるとスケジューラがブロックされてしまうため、負荷のピーク、コンテキストスイッチ、およびランキューの長さを厳密に 同行する. 。さらに、RPS/RFS、GRO/LRO、およびMTUを確認し、バッチ処理やパケットサイズを効果的に活用することも有効です。割り込みの急増を抑えるために、私は以下の点を考慮しています 割り込み合体 また、このレバーが利用可能な場合は、NICドライバでも同様の微調整を行います でござる.
割り込みの割り当てとIRQアフィニティの最適化
シングルコアのボトルネックを回避するため、IRQを複数の CPU, 、irqbalance を使用するか、手動で smp_affinity マスクを設定するか、のいずれかです。その際、既存の NIC キューを参考にし、RSS を有効にして、ハードウェアが着信フローを均等に分散させ、各コアが負荷軽減効果を得られるようにします。 バッチ 。キャッシュの局所性と計画性を維持するため、制御用IRQを「ホットデータパス」と混在させないよう注意しています。アフィニティを適切に設定することで、SoftIRQの処理が特定のコアに滞留しなくなるため、レイテンシが低減され、ドロップも減少します。 残骸. ドライバはしばしばsysfsにキューとCPUの割り当て情報を表示します。そこで、各キューに適切なカーネルが割り当てられているか、非対称性が生じていないかを確認します。より詳細な点については、次のようなガイドを参考にしています。 IRQアフィニティ, 、NUMAの側面やキャッシュの効果についても 考慮に入れる.
実践ガイド：症状から解決策へ
まず、症状を確認します：top での ksoftirqd/cpuN、各コアごとの SoftIRQ の割合は エムピースタット そして、顕著なNET_RXの急増が見られる。その後、/proc/softirqs、/proc/net/softnet_stat、および/proc/interruptsから確かなデータを収集し、支配的なパスや偏った分布を記録する。 続いて、微調整を行います。まず netdev バジェットを調整し、次に IRQ アフィニティと RSS を調整します。それぞれについて、綿密な コントロール. ドロップが引き続き確認される場合は、ドライバの設定、コアレスシングのオプション、オフロード、およびGRO/LROの挙動を確認します。VMやコンテナのホストでは、さらにvNICが物理ホストスタックとどのように連携しているか、またどこで ホットスポット 実際にそうであるかどうか。あらゆる変更について、メトリクスとレイテンシが良好な水準で安定するまで、時系列データを用いて評価しています ランド.
持続可能なパフォーマンスのためのベストプラクティス
SoftIRQカウンタの定期的なモニタリングを定着させます。なぜなら、一定である場合にのみ 透明性 ボトルネックの再発を防ぎます。最新のカーネルバージョンを導入するメリットは、NAPIやスタックが内部的にさらに改善され、それによって厳しい状況に備えた余裕が生まれる点にあります。 負荷 実現する。複数のコアへのバランスの取れた分散は必須であり、スケジューラを縛り付けずに十分な数のパッケージを処理できる適切な予算設定も同様に不可欠だ。HTTPSやAPIトラフィックが多いホスティングプロファイルの場合は、 ホスティングにおけるSoftIRQ, 、なぜならそこでは、NIC、キュー、およびチューニングの選択がサービス品質をどれほど向上させるかが明らかになるからです。キャパシティプランニングでは、CPUコア、NICの機能、メモリ、NUMAゾーンを考慮に入れ、余裕を確保しておくようにしています。そうすることで、 ヒント 到着する。これにより、プラットフォームは高い処理能力を維持し、季節やキャンペーンによる変動にも適切に対応できる。 交通のピーク時.
softnet_statの詳細：数字が本当に意味すること
的を絞って知識を磨き直すために、私は次のような本を読んでいます。 /proc/net/softnet_stat 処理の経過を確認し、特に最初の列に注目してください。最初のフィールドには、CPUごとの処理済みおよび破棄されたパケット数が表示されており、 3列目 時間的制約を示している（要約：予算／時間が不足しているため、NAPIを中止せざるを得ない）。 ドロップ数や時間的制約が負荷に比例して増加する場合は、予算やコアレッシングが最初の対策となります。一方、持続的な増加を伴わないピークが見られる場合、バーストは単に短期的に作業を集中させるだけであるため、大規模な予算設定よりもバッチ処理（GRO）の方が効果的な場合が多いです。 新しいカーネルでは、統計情報にRPS/RFSおよびフロー制限の項目が追加されています。これらが上昇する場合は、RPSを基に意図的に負荷を分散させたり、RFSのルックアップコストがメリットを上回るようになった場合はRFSを削減したりします。私は常にカウンターを /proc/softirqs: 個々のコアで NET_RX が増加し、同時に softnet_stat での時間的制約も高まっている場合、まずは割り当て（IRQ/RSS）に注力し、その次に予算の拡大を検討します。.
RPS/RFS および XPS：ソフトウェア・ステアリングとキュー・チューニングを確実に把握
ハードウェアRSSがない、あるいは不十分な場合は、次のように設定します 回転位置検出 (Receive Packet Steering) を使用して、受信負荷を複数のコアに分散させます。私は rps_cpus を通じて、アクティブなワーカーに適合し、可能な限り NUMAに近い あります。多くのフローでは、私は RFS (Receive Flow Steering) により、着信パケットは対応するソケットが処理される場所で処理されるようになる。フローテーブルがボトルネックにならない限り、キャッシュの局所性には有効である。送信側では、 エックスピーエス （Transmit Packet Steering）：アプリケーションのCPUへのバインディングに合わせてTXキューを選択すること。その目的は、1つのフローが常に同じRX/TXキューおよび同じカーネルを経由するようにすることであり、これによりレイテンシが低減され、 GRO-バッチサイズが大きくなる。私は常に段階的に分散処理をテストしている。まず少数のキューでRPSを有効にし、その影響（ドロップ、%soft、レイテンシ）を測定してから、RFS/XPSを追加する。 RPSによってコアが過負荷になったり、L3ヒット率が低下したりした場合は、CPUマスクを再び縮小するか、キューを該当するサービスのコアにより密に紐づけるようにします。.
NUMA、CPUの分離、およびスケジューラ間の相互作用
メモリアクセスがNUMA間を広く移動してしまうと、どんなに優れた予算配分や割り当てを行っても意味がありません。私は、NIC割り込み、NAPIの処理、およびリクエスト元となるプロセスが、可能な限り同じ NUMAドメイン のままにします。専用のリアルタイムコアやレイテンシコアを備えた構成では、CPUポリシーやCgroupポリシーを用いてこれらを隔離し、意図的にSoftIRQの処理をそこに入れないようにしています。. ksoftirqd 隔離されたコアに到達してはならない。そうしないと、パケットが気づかれないまま蓄積されてしまう。逆に、隔離されたコアがデータパスの終端となる場合、IRQ処理が完全に欠如した状態になってはならない――これは明確なアフィニティと ハウスキーピング- 戦略は必須です。厳格なSLOが求められるワークロードでは、NAPI実行を妨げる可能性のある過度に攻撃的なSCHED_FIFO/RR優先度設定は避けています。 ランキューの長さ、ウェイクアップ、プリエンプション率を監視しています。アプリのインタラクティブ性が高まるにつれてソフトIRQ時間が長くなる場合は、一律に予算を増やすのではなく、粒度やアフィニティを調整するようにしています。.
qdisc、オフロード、Busy-Poll：レイテンシとスループットのバランスをとる
エグレスパスでは、それぞれ キューディスク-CPU時間操作。プロファイルに合わせて手法を選択します。fq_codelはバッファブロート対策となり、バーストを平滑化しますが、一方 mq-マルチキューNICのさまざまなバリエーションに対応しています。安定したリンク上での純粋なデータスループットにおいては、より軽量なqdiscを使用することで、レイテンシのピークを最小限に抑えることができます。イングレス側では、以下の微調整を行うと効果的です。 GRO/TSO/GSO: バッチサイズが大きくなると、SoftIRQの発生頻度は低下しますが、限界状態ではスタック内のパケット処理時間が長くなります。GROフラッシュ間隔やハードウェアオフロードが、アプリケーションに悪影響を及ぼすほど大きな集約を引き起こしていないかを測定しています。レイテンシが極めて重要なパスについては、 busy_poll また、busy_read を適度に調整して、ドライバからパケットを能動的に取り出します――ただし、他のタスクがリソース不足に陥らないよう、注意深く監視しながら行います。同様に、私は 割り込み合体 バースト的なトラフィックの急増に対応するには、マイクロ秒単位で遅延を少し増やすとスループットが向上しますが、増らしすぎるとACKの送信が遅れ、ハンドシェイク時間が長くなります。重要なのは、各変更を個別に評価することです。エミュレートされたバースト、実際の生産ピーク、およびアイドル時間は、多くの場合、異なる遅延プロファイルを示すからです。.
診断チェックリストと安全なロールバック
私は変更作業を行う際、常に以下の簡単なチェックリストに沿って進めています：1) 症状を確認する（ksoftirqd、%soft、Drops）。 2) 割り当て状況を確認する（/proc/interrupts、Queue→CPU、RSS/RPSステータス）。3) 予算を調整し、その効果を softnet_stat 監視する（時間的プレッシャーが軽減され、ドロップが横ばいになる）。4) オフロード／コアレッシングを微調整し、qdisc を確認する。5) NUMA／CPU バインディングおよび cgroups を再確認する。各ステップは、メトリクスの明確な改善、あるいは ロールバック 直近の良好な状態まで。目標値と実測値（レイテンシP95/P99、コアごとの%soft、ドロップ率、コンテキスト切り替え）を記録し、その後の反復作業が闇雲に行われないようにする。 いくつかの小さな改善でも負荷軽減につながらない場合は、その作業を中断し、構造的な原因（キューのボトルネック、アプリのブロック、ストレージの影響）を探ります。 この規律を守ることで、誤った相関関係を防ぎ、スループット数値は向上するものの、インタラクティブ性や安定性を損なう「チューニングの悪循環」から身を守ることができます。.
境界ケースとワークロードプロファイルを明確に区別する
私は、バルク転送、レイテンシが重要なAPI、およびバースト型の処理を意図的に区別しています。 UDP-トラフィック。バルクデータについては、パケット損失が発生しない限り、バッチ処理とコアリセシングを早めに適用します。APIトラフィックでは、たとえ名目上の最大スループットが多少低下しても、均一な分散、バッチサイズの制限、および安定したエンドツーエンド（E2E）レイテンシを優先します。 UDPバーストへの対策としては、キューの拡張とアフィニティ設定を優先的に活用します。そうしないと、予算を過剰に設定した結果、ヘッド・オブ・ライン・ブロッキングが増加するだけです。 環境内でコンテナやオーバーレイホップが多数使用されている場合は、追加のスタック処理を想定し、SoftIRQ負荷をより広範囲に分散させます。 また、ファイアウォール／Conntrackのオーバーヘッドについては別途評価を行います。テーブルが限界に達すると、IRQの分散がどれほど適切であっても、必然的にSoftIRQの負荷は増加します。プロファイルごとのパスが一貫してスリムになって初めて、最後の数パーセントの微調整を行う価値が生まれるのです。.
クラウドおよびコンテナ環境におけるSoftIRQ
仮想化環境では、vSwitch、オーバーレイネットワーク、ホストスタックを通じて負荷が移動するため、ゲストとホストの両方の指標 分析する。ホスト側でSoftIRQの処理時間が長くなると、ゲストシステムが一見余裕があるように見えても、コンテナやVMの動作が直ちに鈍化する。 仕事. そこで、物理NICでのオフロードとコアレッシングを確認しつつ、ホスト側のRPS/RFSがソフトウェア処理パスを適切に分散させているかを確認しています。コンテナワークロードについては、重要なサービスが キュー 餓死する。RSSを備えたマルチキュー対応のvNICは、アフィニティとキューマッピングが適切に設定されていれば、並行処理性能を向上させる。この観点から、データパスを短く保ち、安定化させる 遅延時間 そして、確実で再現性のある性能。.
要約：SoftIRQの解析を確実にマスターする
SoftIRQの負荷を正確に分析するには、明確な測定ポイントを用い、分布を観察し、段階的な ステップ. /proc/softirqs と softnet_stat から始め、ksoftirqd および mpstat と相関関係を分析し、そこから私の 対策. まず、netdev_budget と netdev_budget_usecs を調整し、その後、IRQアフィニティ、RSS、および GRO やオフロードといったバッチ処理オプションを最適化します。各変更は最小限にとどめ、その効果を測定し、プラスの効果が確認された場合にのみ継続して、パケットドロップが解消されるまで行います。 遅延時間 低下する。この規律により、副作用を防ぎ、CPU での並行処理を維持し、トラフィックのピーク時でもサービスを維持する。 レスポンシブ. これにより、Linuxのパフォーマンスは透明性が高く、堅牢で、カスタマイズ可能であり続け、隠れたボトルネックが 安定性 危険にさらす。.
