コンテンツにスキップ 
どのように ソフトアークCPU NAPI、IRQ分配、キュー設計とともに、ホスティングにおけるネットワーク・スループットを制限または解放します。明確な測定ポイント、的を絞ったチューニング、そしてクリーンな親和性により、私は以下を削減します。 遅延時間 そして、生産性の高いサーバーのスループットを一貫して向上させる。.
中心点
これらの核となるアイデアは、CPU、カーネル、NICを経由してネットワークパケットを効率的に伝送し、応答時間を最小限に抑える。 不変 低い。
- NAPI予算 微調整：ポーリングあたりのパッケージ数を増やすことで、オーバーヘッドを削減し、ポーリングをスムーズにします。 CPU負荷.
- IRQバランシング とアフィニティ：ホットスポットを避け、キャッシュヒットを増やす、, 遅延ピーク 押す。.
- マルチ・キュー, RSS/RPS/XPS: フローの並列化、NUMAアライメントの維持、, pps を上げる。.
- オフロード を意識的に使う：GRO/LRO、TSO、合体の評価、, ジッター が見える。.
- 断熱 とビジー・ポーリング：専用ポーリングで予測可能な応答時間 コア.
基本：ネットワーク・トラフィック中にカーネルで何が起こるか
パケットはまずハードウェア割り込みに着地し、その後カーネルが次の作業を引き継ぐ。 ソフトIRQ とNAPIポールのループがある。私は、高速HardIRQフェーズが本当に短いままであることを確認し、実際のロジックが適切なコンテキストに移動するようにします。 CPU時間 は消滅しない。ksoftirqdスレッドは、直接処理が不可能な場合にのみ介入し、継続的な負荷がかかるとすぐにキューに入る。これはまさに待ち時間が発生する場所であり、TTFBの増加やスループットの変動に反映される。より深く掘り下げたい場合は、IRQ処理に関する実践的な知識を以下の記事で見つけることができる。 割り込み処理とCPU性能, これはカテゴリー分けに使っている。.
NAPI、SoftIRQ、ksoftirqd：レイテンシを管理する代わりに制御する
NAPIは、定義されたバジェット内で1回の実行につき複数のパケットをピックアップすることにより、割り込みの嵐を減らし、割り込み時間を最小限に抑える。 オーバーヘッド を下げる。予算が足りなければ、小包は山積みになり、ソフトバンクは熱くなり、そして レイテンシー が明らかに増加する。このような状況では、/proc/softirqsと/proc/net/softnet_statを系統的にチェックし、ドロップやtime_squeeze、キューのオーバーフローを可視化する。それからnet.core.netdev_budgetやnet.core.netdev_budget_usecsを徐々に増やし、CPU負荷、p95/p99分布、パケットロスを並行して監視する。コツは、ユーザーランドのスレッドのインタラクティブな実行を混雑させることなく、ポーリングごとに十分な仕事をこなすことだ。.
IRQバランシングとアフィニティ：ホットスポットの回避、キャッシュヒットの増加
NICのIRQをすべて持つ単一コアは、割り込み、ソフトIRQ、アプリのスレッドに対応しなければならないため、ボトルネックになる。 IRQ をターゲットにしている。irqbalanceサービスは助けになるが、高いppsレートの場合は、アフィニティを使ってRX/TXキューを適切なものに明示的にマッピングする。 カーン. .NUMAシステムでは、リモートメモリアクセスを避けるために、キューを同じノードのコアにバインドする。アプリケーション・スレッドは、隣接しているが別々のコアで実行されるため、キャッシュのローカリティとスケジューラビリティが向上する。この戦略的ディストリビューション・ガイドは、次のような戦略的ディストリビューションの概要を提供している。 データセンターにおけるIRQバランシング, これは微調整のために参考にしている。.
マルチキュー、RSS/RPS/XPS：並列化を正しく使用する
最近のNICには、いくつかのRX/TXキューが搭載されており、それらは以下の方法で制御できる。 RSS をフローに割り当てることで、実際の並列性を実現している。カードが提供するキューが少なすぎる場合、私はRPS/XPSを使って、フロー間でパケットを賢く分配するためにソフトウェア側で調整を行う。 カーン をプッシュする。フローが常に同じCPU上に残り、高価なキャッシュの歪みが発生しないように、クリーンなハッシュ分散が重要だ。同時に、TXパスとRXパスを近づけることで、ロックの競合や不要なクロスノードアクセスを回避している。これにより、1つのコアがブレーキをかけることなく、ppsスループットが向上する。.
CPUとの親和性をユーザー空間へ：エンド・ツー・エンド思考
私は、NIC-IRQからNAPIキューを経由してアプリのワーカースレッドへのデータパスを計画し、不要なフックなしにパケットが目的地に到達するようにする。 応答時間 は一定である。これを実現するために、私は一貫して割り込み/ソフトIRQ用のコアをアプリのコアから分離し、アプリケーションのコアと割り込み/ソフトIRQ用のコアを明確に分離している。 親和性-ルールがある。ウェブサーバー、リバースプロキシ、データベースには、パスを短く保つため、IRQコアに近い固定CPUセットが与えられている。さらに、クロックの変化がジッターをp99に押し込まないように、CPUガバナーをパフォーマンスに設定している。この一貫した割り当てにより、動作が予測可能になり、ボトルネックをきれいに診断するのに役立つ。.
オフロード、GRO/LRO、ファイアウォール、eBPF: やみくもに飛ばすことなく負荷を節約
セーブ・チェックサム・オフロード、TSO、合体 CPU時間, しかし、パケットサイズやバーストの挙動、ジッターを変えることができる。GRO/LROはフレームを束ね、スタックの負荷を軽減するが、リアルタイムの要求に対しては、私は状況に応じて以下のことを決める。 活動停止 または用途が限られている。Conntrackテーブルと深いnftables/iptablesチェーンにはクロックがかかるので、余計なルールを整理してパスを単純化する。必要であれば、eBPF（XDP、tc-BPF）に頼って、NICで早期に決定を下し、コストのかかるパスを回避する。微調整を実践するための良い出発点は、以下の概要である。 割り込み合体, これはレイテンシーを考慮したバジェットである。.
ビジー・ポーリングとCPU分離：応答時間のロック
待ち時間が長いターゲットに対しては、ビジー・ポーリングを使って、ユーザー空間のソケットがより早くパケットを拾えるようにしている。 待ち時間 短縮する。これによって負荷は増えるが、APIやトレーディングのワークロードのために、非常に狭いp99ディストリビューションを専用機で提供することができる。 コア. .さらに、isolcpus=、nohz_full=、rcu_nocbs=でコアを分離し、タイマー、RCU、システムサービスがハウスキーピングCPUでのみ実行されるようにしている。このように分離することで、レイテンシーコアでの干渉を防ぎ、動作の再現性を高めている。その結果、専用コア、早期パケット収集、定義された予算という明確なロードマップが得られた。.
モニタリングとトラブルシューティング：症状から原因へ
私は、まずpps、スループット、コア負荷から始め、次にドロップとアクティビティのチェックをします ksoftirqd-スレッドのパターンを確実に認識するためだ。sar、htop、ss、nload、ethtoolなどのツールは、いつ、どこで輻輳が発生するか、また キュー が限界に達する。夕方のピーク、クーロンウィンドウやキャンペーンが失われないように、平均値ではなく分布が重要です。私は、TTFBのピークをIRQ分布、NAPIバジェット、オフロード設定と関連付け、的を絞った調整を行います。IRQアフィニティを調整したり、NAPIバジェットを新たに調整したりするだけで、タイムアウトが顕著に減少することがよくあります。.
チューニング・パラメーター一覧
以下の概要は、私が恒久的な変更を加える前に、変更を賢く使い、効果を明確に割り当てるのに役立つ。 ロールアウト 計画を立てる。各調整を繰り返しテストし、待ち時間の分布を測定し、次のような副作用を観察する。 CPU そしてメモリー。原因と結果が明確になるように、テストウィンドウごとに1つのポイントしか変更しない。そして結果を文書化し、アラートのしきい値を設定する。こうすることで、生産的なトラフィックで不意打ちを食らうリスクを冒すことなく、再現可能な改善を達成することができる。.
| パラメータ/機能 | データパスにおける影響 | 育成／活動開始の時期 | リスク／副作用 |
|---|---|---|---|
| net.core.netdev_budget | NAPI世論調査ごとのパッケージ数 | softnet_statのドロップについて | 長い投票がユーザーのスレッドを置き換える |
| net.core.netdev_budget_usecs | 投票ごとの時間制限 | 大バーストによるジッター | 小さすぎる：もっと文脈を変える |
| RSS/RPS/XPS | フローをコアに分散させる | コア上のホットスポットの場合 | 不正確なハッシュ：キャッシュの歪み |
| IRQアフィニティ | IRQをコアの近くにバインドする | NUMAミスマッチ | 配置ミスが新たなホットスポットを生む |
| GRO/LRO/TSO | パッケージ数を削減 | CPUボトルネック用 | ジッター、より大きなバースト |
| ビジー・ポーリング | 小包の早期回収 | P99のタフなターゲットに | CPU消費量の増加 |
RX/TXリングとキューの深さ：ディメンションバッファが正しい
IRQが適切に分配され、適切なバジェットが設定されていても、NICリングが小さすぎたり大きすぎたりすると、パフォーマンスが低下することがあります。そのため、私はカードのRX/TXリングサイズをチェックし、バーストキャラクターとレイテンシの目標値に合わせます。小さすぎるリングは、トラフィックのピーク時にNICのドロップを引き起こし、ドライバの統計でrx_missed_errorsやfifo_errorsとして表示される。大きすぎるリングは、輻輳を偽装し、レイテンシを増加させ、p95/p99で長いトレーリングエッジを作成します。短いバーストを吸収するのに十分なバッファがあるが、キューでパケットが “老朽化 ”するほどではない。.
さらに、ホスト側の tx_queue_len とQdiscを使用している。sch_fqまたはfq_codelを使えば、バースト動作をスムーズにし、ペーシングによって大きなTSOパケットを分散させることができます。これにより、スイッチ・ポートでのマイクロバーストが減少し、待ち時間曲線がより滑らかになります。これは、小さなRPCが大きなアップロードと同時に実行されるような混合ワークロードにとって重要です。私はethtoolの統計情報をモニターし、softnet_statと相関させて、輻輳がNICリングで起きているのか、netdevのバックログで起きているのか、Qdiscで起きているのかを認識しています。.
MTU、ジャンボフレーム、セグメンテーション
仝 エムティーユー は、過小評価されがちな古典的なてこである。ジャンボフレームはGビット/秒あたりのパケット数を減らし、CPUの負荷を軽減する。ただし、パスが本当にエンド・ツー・エンドでジャンボフレームに対応している場合に限る。そのため、私はリモート・ステーション、スイッチ、トンネルを系統的に検証している。どこかで1500に戻るフラグメントがあるとすぐに、パスのMTUの問題、再送、不要なパケットを送信する危険性がある。 ジッター. .東西の通信が支配的なデータセンターでは、同種の9k戦略が有効である一方、インターネット向けのワークロードでは1500がより安定した選択肢となることが多い。.
私はいつも、MTUを次のように評価している。 TSO/GSO/GRO過度に積極的なバンドルは、アップストリームバッファを満たし、待ち時間のピークを発生させるTXの大きなバーストにつながる可能性がある。送信側での賢明なセグメンテーション、十分なペーシングメカニズム、リアルタイム要件を阻害することなく受信側での作業を節約するGROなど、一貫性のあるパスを目指す。.
UDP、QUIC、ストリーミング・ワークロード：仕様を検討する
すべてのトラフィックがTCPというわけではない。. UDP-重いプロファイル（DNS、VoIP、QUIC、遠隔測定）は、RSS/RPSとGROで挙動が異なる。最近のスタックはUDP-GRO/GSOをサポートしており、CPUの負荷を減らすことができる。私はこれを選択的に使用し、並び替えのリスクやジッターが増加するかどうかを測定している。NICが提供するRSSキューが少なすぎる場合はRPSが助けになるが、ホットキャッシュフローを「ばら撒いてはならない」。TX側では エックスピーエス を使用して伝送パスを束ね、ロックの競合を減らすことができる。実際には、静かでコア・アッフィンのアロケーションは、特に、すべてのキャッシュ・ヒットが重要である多くの中規模のUDPフローで、利益をもたらす。.
仮想化とコンテナ：ホスト、ゲスト、ホストのクリーンな統合
仮想化環境では、ホスト、ホストスレッド、ゲストIRQの間で作業がシフトする。私は ボストネット-スレッドは独自のコアを受け取り、アプリワーカーと衝突しない。それらの親和性は物理的なRX/TXキューと一致しなければならず、そうでなければ不必要なCPU間マイグレーションが発生する。ゲストでは、virtio-netキューをチェックし、マルチキューを有効にして、ベアメタルに類似したRSS/RPSをセットアップする。レイテンシとppsが前景にある場合 SR-IOV VF、vCPU、メモリが同じノードに属するという一貫したNUMAトポロジーが前提条件です。.
コンテナ・スタックでは、オーバーレイ・ネットワーク、深いNATチェーン、複雑なCNIトポロジーによって、ホップが追加される。レイテンシがクリティカルなサービスでは、hostNetworkかリーンネットワーク（macvlan/ipvlan）を好み、NATパスを均等化し、以下のようにする。 コンントラック をできるだけ小さくする。一貫したCPU戦略が重要である。ホストのIRQとNAPIコアは、vhost/containerワーカーが動作しているコアの近傍に配置すべきである - これがデータパスを短く予測可能に保つ唯一の方法である。.
スケジューリング、Cステート、IRQスレッディング
なぜなら、待ち時間は計算時間だけではないからだ。 起床時間 私はレイテンシーコアのディープCステートを最小限に抑えている。積極的なパワーセーブは、SoftIRQが実際に実行されるまでに数ミリ秒を要することがある。そのため、私はパフォーマンス・ガバナーに頼り、深いCステートを制限し、ターボを一貫したものに保つことで、周波数ジャンプを予測可能にする。同様に重要なのは IRQスレッディングドライバが許可しているところでは、IRQスレッドに作業を移し、ユーザーランドを完全に置き換えることなく、RXがダウンストリーム作業より先に開始されるように優先順位をつける。スケジューリングポリシー、アフィニティ、バジェットの相互作用は厄介だ。私は一歩一歩テストし、p99を記録し、そうでなければ秘密のボトルネックになるksoftirqdとの干渉に注意する。.
観測の詳細：トレースポイント、カウンター、ヒストス
メトリクスが曖昧なままであれば、私はもう一段階深く踏み込む。 netif_receive_skb, napi_poll そして net_dev_queue, を使用して、ポーリング時間、パケット量、および待ち時間をヒストグラムとして表示することができます。このような分布は、1 % のポーリングが長すぎるのか、あるいは個々のキューが不足しているのかを示します。さらに、ethtoolrx/tx-counters、TCP retransmits、busy poll hits、softnet_statは、パケットがどこで失われているかを明確に示してくれる。私はドロップ解析を使って、NICがドロップしているのか（リングが一杯になっている）、netdevのバックログが崩壊しているのか（time_squeeze）、Qdisc/ファイアウォールがスローダウンしているのかを認識します。これらのパズルのピースが組み合わさって初めて、私はリング、バジェット、オフロードを調整します。.
セキュリティとフィルタリングパスの合理化
複雑なACL、深いnftables/iptablesチェーン、広いconntrackテーブルは、パケットごとに一定のレイテンシーを追加します。私はルールを統合し、セット/マップと連携し、一般的なドロップを可能な限りパスの前方に移動させる。レイテンシーが重要な場合は、NIC（XDP/clsact）で可能な限り早期に移動させるのが理想的だ。ステートレスフロー、テレメトリー、既知の “安全な ”ポートは、ターゲットを絞って使用することができる。 トラッキングなし を使用して、コストのかかるルックアップの必要性を排除している。同時に、ステートテーブルを新鮮に保ち、負荷のピークに合わせてハッシュサイズを調整し、積極的に孤児となったエントリーを整理する。ゴールは、プロファイルで永続的な負荷として目立たない、クリーンで追跡可能なポリシーパスである。.
典型的なアンチパターンとそれを回避する方法
- すべてのIRQを1つのコアに： 輻輳とホットなksoftirqdにつながる。解毒剤：NUMAコヒーレントで、キューごとにターゲットを絞ったアフィニティ。.
- リング/予算のブラインド最大化： 輻輳を隠し、待ち時間の尾を長くする。対策：段階的に増加させ、分布を測定する。.
- フローハッシュの設定が不適切： フローがコア間を飛び交い、キャッシュが空回りする。解毒剤：安定したRSSキー、明確な目的を持ったRPS/XPSのみ。.
- SoftIRQと同じコアのアプリのスレッド： 干渉とジッター。対策：ハード分離、近隣割り当て。.
- 予算なしのオーバーレイ／NAT： 各ホップに追加される。対策：パスを合理化し、遅延ワークロード用のホストネットワークを構築する。.
- レイテンシーコアの省電力化： 深いCステートは反応を鈍らせる。解毒剤：パフォーマンスガバナー、Cステートの制限。.
- 測定なしでオフロード： TSO/GRO はバーストとジッターを悪化させる可能性がある。対策：ワークロードをアクティブにし、P99をモニターする。.
実践的ホスティング：効果的なステップ
私はクリーンな測定段階から始め、ベースラインを設定し、すべての変更を短い時間枠で小さく抑える。 原因 を分離することができる。その後、irqbalanceを起動させ、自動分配をチェックし、必要であれば手動でアフィニティを設定する。 ホットスポット が見えなくなった。その後、マルチキュー、RSS、そして必要に応じてRPS/XPSをセットアップし、NUMAと同期させる。アプリのワーカーをIRQコアの近辺のコアにバインドするが、直接衝突しないようにする。最後に、ファイアウォールパスをパージし、contrackテーブルをチェックし、レイテンシーターゲットに基づいてオフロードを意識的に決定する。.
P99のレイテンシーに関するプレイブックの例
まず、代表的な負荷と/proc/softirqsと/proc/net/softnet_statからのセキュアなログを使ってp95/p99を測定し、次のことを行う。 ドロップス とtime_squeezeがはっきり見える。それから、netdev_budgetまたはnetdev_budget_usecsを段階的に増やし、各変更の後にp99を押したままにしておくと、実際のnetdev_budgetとusecsを見ることができる。 トレンド を認識している。並行して、IRQをNUMAノードのコアにバインドし、アプリのワーカーを適切な隣接ノードに移動させる。p99がジャンプし続けるようなら、GRO/LROバリエーションと割り込み合体プロファイルを、それぞれ短い測定パスでテストする。ディストリビューションが安定しているときだけ、Ansibleロールやsystemdドロップインに設定を移します。.
管理者向けショートバージョン
私は次のような方法で最大の力を発揮する。 ソフトIRQ, NAPIバジェット、IRQアフィニティ、アプリのスレッドをコヒーレントなデータパスとして使用します。ネットワーク作業をコアに分散させ、NUMAコヒーレントキューを維持し、ワーカーを適切に接続することで、次のようなことが可能になります。 ルート 簡潔に言おう。私は、スループットをやみくもに最適化するのではなく、オフロードを意図的に設定し、ジッターを測定する。ハードなレイテンシターゲットに対しては、ビジーポーリングとCPUの分離に頼る一方、ハウスキーピングCPUは干渉を遮断する。これらのステップを規律正しく実行すれば、一定のスループット、より狭いレイテンシ分布、負荷ピークに予測可能に反応するホスティング環境を得ることができる。.
