割り込み合体 は、複数の受信パケットを1つのハードウェア割り込みにバンドルし、スループットを向上させながらCPU負荷を軽減します。タイミング、しきい値、およびRSSやRSCなどのNIC機能を調整し、レイテンシー、ジッター、およびパケットを最小限に抑える方法を紹介します。 スループット 仕事量による。.
中心点
概要技術、チューニング、練習を通して、以下の核となる側面が構造的にあなたを導く。.
- CPUアンロード割り込みが少なく、スループットが高い。.
- レイテンシーのトレードオフ安定性とppsに対するミリ秒。.
- NICチューニングRSS、RSC、MTU、BIOSエネルギープロファイル。.
- OSセットアップethtool、RSC/RSS、ドライバーキュー。.
- モニタリングpps、割り込み/秒、p99レイテンシー。.
割り込み合体についての簡単な説明
合体 つまり、ネットワーク・カードが受信パケットを収集し、十分な仕事があるかタイマーが切れたときだけ割り込みをトリガーする。こうすることで、割り込みの数を大幅に減らし パケット処理 をNICに送ることで、CPUの負荷を軽減することができる。Windowsサーバーでは、Receive Segment Coalescing (RSC)が、複数のセグメントをより大きなブロックにまとめ、処理コストを削減するのに役立つ。Linuxでは、フローの特性とターゲットのレイテンシーに応じて、rx-usecs（時間）とrx-frames（パケット）を使って集約を制御している。このアプローチは、オーバーヘッドを減らし、コアを空け、トラフィックが多いときのスループットを安定させる。意図的な妥協は依然として重要である。各サマリーにはわずかな待ち時間が追加されるが、これはレイテンシが重要なフローに対しては厳しく制限している。.
メカニクスタイミング、FIFO、しきい値
NIC 受信フレームをFIFOキューに保持し、2つの基準に従って割り込みをトリガーする。低レイテンシのサービスには小さなタイムウィンドウを設定し、大きなバーストを伴う高スループット・ストリームにはタイムウィンドウを大きくする。受信キュー1つにつき1つのキューを使用することで、並列化が改善され、割り込みの節度によってコアの変更が減り、キャッシュがより有効に使用される。しかし、rx-usecが高すぎると遅延が増え、低すぎると割り込みストームが発生し、キャッシュがプッシュダウンする。 スループット. .そのため、MTU、フレームサイズ、小さなパケットの割合に応じて、タイムアウトとパケット制限のバランスをとっている。.
アダプティブ・モデレーションとバースト検出
適応的合体 時間ウィンドウとパケットウィンドウを動的に現在の負荷に適応させます。私は、負荷プロファイルが大きく変動するときにこれを使用している。低いppsレートでは、ウィンドウは小さいまま（低レイテンシー）であり、ppsレートが上がると、ウィンドウは広がる（CPUの負荷を減らす）。NICによってはバーストを検知してrx-usecを増やすものもあれば、固定レベルで動作するものもあります。私は 安定性 アダプテーションを有効にした場合のp99のレイテンシのグラフ。決定論的なサービスの場合、私は静的で細かく選択されたしきい値を設定することを好む。.
スループット対待ち時間：制御可能な妥協点
レイテンシー しかし、その場合、CPUの動作が大幅に増加し、負荷時のスケールが小さくなる。ファイル転送、ストリーミング、レプリケーションでは、安定性とネットスループットが向上するため、多少の遅延は許容する。VoIP、リアルタイムゲーム、HFTの場合は、遅延を最小限に抑え、モデレーションをオフにします。また TCP輻輳制御, なぜなら、CUBICやBBRのようなアルゴリズムは、パケットロス、RTT、バースト時の動作に強く影響するからです。細かく調整されたタイマー、RSS、適切なTCPパラメーターにより トレードオフ 測定可能な最適化。.
送信合体、TSO/GSO/GROおよびLRO
RXに加えて TX合体 tx-usecsとtx-framesは、送信パケットを束ねることで、コンテキスト・スイッチを節約し、送信スループットを安定させる。私は、大量の送信をスムーズにするために適度なtx-usecsを使用しているが、短いレスポンス（HTTP APIなど）を素早く送信する必要がある場合は、tx-usecsを小さくしている。以下のようなオフロードがある。 TSO/GSO 送信前にセグメントを拡大し、パケット数を減らす。 GRO/LRO RX側でセグメントをマージする。ファイアウォールやキャプチャの要件によっては、LROを減らしてパケットの境界を見えるようにしています。全体として、私はPPSを減らし、不必要に応答時間を伸ばすことなくカーネルがSoftIRQに費やす時間を減らすように、TX合体およびオフロードを組み合わせている。.
ホスティングサーバーのNICチューニング
RSS (Receive-Side Scaling）は、受信フローを複数のコアに分散させ、1つのコアがブレーキになるのを防ぐ。私はRSSを有効にして、マルチコアCPUが効率的に動作するように十分な受信キューを設定している。RSCはまた、小さなセグメントをマージすることで負荷を軽減し、スタック内のパケット数を減らす。ホスティング・ワークロードの場合は、Cステートやディープ・スリープ・モードがレイテンシーを増加させないように、BIOSのクリーンなMTU選択、DSCP/QoS優先順位付け、CPUパワー・プロファイルと合体させる。負荷のピーク時に組み合わせをテストし、IRQアフィニティとキューのピン留めがキャッシュのローカリティを維持するかどうかをチェックします。こうして ホスティング・チューニング そして、合体ネットワークを中断させる。.
NUMA、MSI-X、フローステアリング
マルチソケット・ホストの場合、私は次のことに注意している。 NUMA-メンバーシップ：受信キューをPCIeスロットに近いコアに固定し、関連するワーカースレッドを同じNUMAノードに配置する。. 三井住友海上エックス-各RX/TXキューが独自の割り込みを持ち、ロックの保持が少なくなるようにするためだ。さらに RPS/RFS/XPS, を使用して、フローを「適切な」コアに誘導し、送信割り当てを制御している。L1/L2のミスレートを測定し、コアをまたぐトラフィックが増加するかどうかを観察する。もしそうであれば、キューを再配置するか、キューの数を減らして局所性を高める。.
パラメータとその効果（表）
パラメータ rx-usecs、rx-frames、RSSキュー、RSCなどの値によって、待ち時間を最小にするか、スループットを安定させるかを決める。私は保守的な値から始め、p99のレイテンシーと1秒あたりの割り込みを測定し、それから慎重にタイムウィンドウを増やしていく。スモールステップにすることで、効果の帰属を容易にし、誤解を防ぐことができる。バーストが支配的な場合は、rxフレームを少し増やし、ジッター分布をチェックする。混合ワークロードの場合は、VLANまたはNICプロファイルごとに以下のように変化させます。 フロー を、それぞれ異なる目的で別々に最適化する。.
| パラメータ | 効果 | リスク | こんな人に向いている |
|---|---|---|---|
| rx-usecs（時間） | CPU-遅延窓からの救済 | 短いフローの待ち時間が増える | 高スループット、バックアップ、レプリケーション |
| RXフレーム（パッケージ） | 小さなパッケージを1つにまとめる 割り込み 一緒に | バースト用のキュー充填 | 多くの小型パッケージ、ウェブトラフィック |
| RSSキュー | 数回にわたるスケーリング処理 カーン | 不正確なピン止めはクロスコアトラフィックを増加させる | 10-100 Gbit/sのマルチコアホスト |
| RSC/RSSアクティブ | 荷物の量が少ない スタック | 超低遅延には不向き | ホスティング、仮想化、ストレージ |
解釈短いフローが支配的な場合は、rx-usecsの最小値に影響を委託する。バルク転送の場合は、より高い値を設定し、割り込みレートの低下の恩恵を受ける。各ステップの後にp95/p99のレイテンシとPPSをチェックし、設定ミスを避ける。負荷が高まるにつれて、私はソフトIRQの時間とコンテキスト・スイッチを監視し、CPUの時間が本当に有益なところに流れるようにする。きれいなIRQアフィニティ・レイアウトは、コア間の割り込みのさまよいを防ぎ、次のようなことを節約する。 キャッシュ-ヒット。.
実習：ウィンドウズ・サーバーとリナックス
ウィンドウズデバイスマネージャーでNICのプロパティを開き、„詳細 “を選択し、必要に応じて割り込みモデレーション、RSS、RSCを調整する。Cステートで応答時間が長くならないように、電源プロファイルをハイパフォーマンスに設定します。. リナックスethtoolを使ってrx-usec/rx-framesを調整し、ethtool -Sを使ってIRQカウンターとエラーカウンターをチェックする。irqbalanceまたは明示的なアフィニティピニングによって、コアにキューを割り当てる。irqbalanceまたは明示的なアフィニティ・ピニングでコアにキューを割り当てる。非常に小さなパッケージの場合は、GRO/LROを試して、ユーザーパスとカーネルパスのどちらがボトルネックになっているかをチェックする。このトピックについては、以下のガイドで詳しく説明している。 CPU割り込みの最適化, これは、測定可能なステップとカウンターチェックを記述したものである。.
仮想化とクラウド：SR-IOV、vSwitch、vRSS
仮想化環境では パス パッケージの最適設定。と SR-IOV VFはvSwitchのオーバーヘッドをバイパスします。私はPF/VF上で直接合体を設定し、ゲストとホストが同様のポリシーを持つようにします。vSwitchシナリオ（Hyper-V、Open vSwitch）では、追加のキューとスケジューラが関与します；; ブイアールエスエス はVM内の負荷を複数のvCPUに分散する。私は、合体がホストとVMのどちらに効いているかを測定し、大きすぎるウィンドウによる二重のモデレーションを防ぎます。NFV/DPDKワークロードの場合、作業はユーザー空間にシフトされます。そこでポーリングバジェットを調整し、カーネルの合体を控えめにして、測定値を改ざんしないようにします。.
パフォーマンス測定と遠隔測定
測定 そのため、私はpps、バイト/秒、割り込み/秒、SoftIRQ時間、ドロップ、キューの長さを追跡している。p50/p95/p99のレイテンシーを比較し、バーストの挙動に注意を払う。HTTP/2/3については、合体による副作用を認識するために、接続密度、リクエスト・レート、リクエストごとのCPU時間を測定する。ボトルネックはスタックレイヤー間を移動する傾向があるため、iowait、IRQ負荷、ネットワークレイテンシを一緒に見ると、ストレージノードが恩恵を受ける。. ダッシュボード イベントとデプロイ時間を使用することで、チューニングのステップを明確に割り当て、リグレッションを即座に止めることができます。.
タイムクリティカルなプロトコルとハードウェア・タイムスタンプ
を持つプロトコルの場合 正確な時間測定 (PTPなど)、合体がタイムスタンプの精度に影響するかどうかをチェックします。NICの中には、合体前に設定されるハードウェアタイムスタンプを提供するものもある。このような場合、LRO/GROを非アクティブにし、rx-usecsを最小にすることで、レイテンシ・バリアントが時間同期に干渉しないようにします。決定論的ネットワーク（TSN）の場合は、省エネモードをフラットに保ち、QoSを厳密に設定し、クロックの安定性を脅かすオーバーフローを発生させるキューがないことを確認する。.
ワークロードプロファイル：いつ作動させ、いつ作動させないか？
高いスループットバックアップ、CDNオリジン、オブジェクト・ストレージ、VMレプリケーションは、CPUの妨害が少ないため、合体によって大きな恩恵を受ける。. ウェブホスティング RSSと良好なキャッシュローカリティを組み合わせることで、多くの小さなリクエストに適度な値が必要になります。仮想環境では、vNICごとにスマートなデフォルトを設定し、ノイズの多い隣人を隔離する。VoIP、ゲーム、リアルタイムの遠隔測定では、モデレーションを無効にするか、非常に厳しいタイマーを設定します。10Gbit/sのバルク・トラフィックと1Gbit/sのAPIトラフィックでは挙動が異なるため、トラフィック・プロファイルに応じた測定は必須です。.
リングサイズ、バッファ、ドロップの動作
タイマーに加えて リングサイズ (RX/TXディスクリプタ）は、バースト時の信頼性を確保するためです。短いピークでドロップが発生する場合は、メモリフットプリントとキャッシュフィットネスに注意しながら、RXディスクリプタを適度に増やす。大きすぎるリングは問題を隠しますが、パイプラインの待ち時間を長くします。統計カウンターで „rx_no_buffer“、„droped“、„overruns “を監視し、しきい値を典型的なバースト長と比較する。rx-frames、rx-usecs、リングサイズを絶妙なバランスで組み合わせることで、以下を防ぐことができる。 バースト ロスやジッター・ピークにつながる。.
ジッター、パケットロス、バースト処理
ジッター 合体ウィンドウとバーストパターンが不利に相互作用するときに発生する。小さなタイマージャンプは、スループットを目に見えて低下させることなく、p99カーブを滑らかにすることが多い。もしNICが負荷で落ちるようなら、私はよりアグレッシブでない値を設定し、キューの深さとドライバーのステータスをチェックします。ウェブサイトについては、以下を分析するのに役立ちます。 ネットワーク・ジッター, レンダリングブロックリクエストとTLSハンドシェイクを計画可能にする。最後に、QoSポリシーが優先度クラスをきれいに分け、その結果、重要な フロー を好む。.
実践的チューニング・チェックリスト
スタート ベースラインで：各変更の前に、レイテンシー、pps、割り込み/秒、CPUプロファイルを記録している。それからRSS/RSCをアクティブにし、適度な合体値を設定し、p50/p95/p99を再び測定する。その後、ジッターやp99のレイテンシーが増加するまでrx-usecsを少しずつ増加させ、最後の良いポイントまでロールバックします。固定コアにキューを割り当て、キャッシュ・ミスを監視し、もしクロスコア・トラフィックが増えたら、アフィニティーを調整する。各変更を簡単に文書化し、負荷のピークを比較する。 安定性 密かに苦しむことはない。.
リンク速度による開始値の例
- 1Gbit/srx-usecs25-50、rx-frames8-16、tx-usecs25-50；RSSキューは少ない（2-4）、レイテンシー重視。.
- 10Gbit/srx-usecs50-100、rx-frames16-32、tx-usecs50-100；4-8 RSSキュー、GROオン、LRO選択。.
- 25/40 Gビット/秒8-16キュー、NUMAピニング厳密、RSC/RSSアクティブ。.
- 100Gbit/s16-32キュー、MSI-Xをフル活用し、リングサイズを適度に大きくする。.
ヒントこれらは保守的なエントリーポイントです。私はp99のレイテンシーとドロップに沿って最適化し、パケットサイズ（MTU 1500対Jumbo）、フローミックス、CPUトポロジーを考慮します。.
コスト、エネルギー、持続可能性
エネルギー CPUが実行するコンテキスト・スイッチやウェイクアップの回数が減るため、割り込みレートを上げると、割り込みの回数が減ります。データセンターでは、これは多くのホストに加算され、電力と冷却コストを顕著に削減する。最新の10/25/40/100G NICにアップグレードすると、通常数百ユーロかかるが、1バイトあたりのCPU使用時間が減るため、すぐに元が取れることが多い。ランニングコストを低く抑えるために、ライセンス、ドライバーのメンテナンス、モニタリングがすでに行われているかどうかも考慮します。SLAが重要なサービスでは、保守的なウィンドウを使用する価値があります。 ジッター ユーザーエクスペリエンスを制限し、確保する。.
トラブルシューティングとアンチパターン
メトリクスの表示 割り込みの嵐, RSSキューを減らすか、rx-usecsを少し増やす。レイテンシーカーブが „不安定 “な場合は、テストとしてアダプティブ・モデレーションを解除する。高いCPUリザーブにもかかわらずドロップが発生する場合は、リングサイズ、ファームウェアのバージョン、PCIeリンク状態のパワーマネージメントをチェックする。典型的な例：非常に高い合体＋GRO/LROアクティブはp50のパケットロスをマスクするが、p99は苦しんでいる。マルチテナントホストでは、„ノイジーネイバー “がIRQ負荷の不均等な分散を引き起こす。 フロー を使用して保護します。重要：原因と結果を明確に分けるため、変更は必ず個別に展開し、同一の負荷プロファイルに対してテストを行うこと。.
要約：より速く、よりスムーズで、より予測しやすい
コア・アイデア割り込みの合体によって干渉が減り、作業がよりスマートに分散され、タイマーとパケット制限を目標通りに設定する限り、ネットスループットが向上する。高スループットのサービスでは、より余裕のあるウィンドウを選択し、リアルタイムサービスでは、モデレーションを最小にするか無効にします。RSS、RSC、MTUディシプリン、クリーンなIRQアフィニティでマルチコアCPUをフル活用している。p95/p99、割り込み/秒、SoftIRQ時間による測定は、すべての変更を確実にし、誤解を防ぐ。だから私の ネットワーク 負荷がかかっても静かで、応答が速く、ホスティングやアプリケーションに予測可能なレイテンシーを提供します。.
