サーバーと仮想マシン

10 Gbit/s および 25 Gbit/s におけるレシーブサイドスケーリング：最新の Linux サーバーネットワークのためのパフォーマンスチューニング

受信側スケーリング 10 Gbit/sおよび25 Gbit/sのリンクにおいて、ネットワークトラフィックを複数のコアに適切に分散させ、Linuxサーバーが低遅延で高いスループットを実現できるようにします。ここでは、RSSを有効にする方法を実践的な例を交えて説明します。 キュー Coresのマップ上に配置することで、割り込みやキャッシュヒットにおけるボトルネックを回避する。.

中心点

次のステップを素早く計画できるよう、重要なポイントを簡潔にまとめます。.

負荷分散: パケットは、複数のキューを経由して複数のコアに割り当てられる。.
キャッシュの局所性: フローは常に同じキューに保持されます。.
ハッシュ: 4-タプルハッシュは、フローをキュー間で均等に分散させる。.
親和性: 適切なIRQマッピングにより、レイテンシが低減されます。.
スケーリング: 10/25 Gbit/s 以上で、RSS は高いスループットを確保します。.

これらの点は相互に関連し合い、その パフォーマンス 実際のワークロードについて。まず、適切なキュー数を優先し、次に CPU-アフィニティ。その後、ハッシュパラメータと微調整を確認します。.

レシーブ・サイド・スケーリングの機能

RSSはパケット受信をいくつかに分割します 受信キュー, 、これを特定のCPUコアに割り当てることで、単一のコアがボトルネックになるのを防いでいます。これにより、ハード割り込みのピークが抑えられ、ソフトIRQを介して処理が平滑化されるため、レイテンシのピークが低減され、スループットが向上します。各キューは独自の割り込みをトリガーし、データパスの一貫性を保つために、それらを特定のコアに固定的に割り当てています。この一貫性により、 キャッシュ-局所性。なぜなら、フローは常に同じコアに到達するからです。まさにこの相互作用が、高いPPSレートにおいて、測定可能な効率性に直接つながるのです。.

RSSの技術的な仕組み

NICは、送信元/宛先IPおよび送信元/宛先ポートから ハッシュ そして、これをキューを指すインダイレクション・テーブルのインデックスとして利用します。これにより、あるフローのパケットは常に同じキューに振り分けられ、その結果、同じカーネルに紐付けられたままとなります。ハッシュキーとプロトコルフィールドが適切に設定されていれば、異なるフローは均等に分散されます。これにより、処理はほぼ ハードウェア, これによりカーネルの負荷が軽減され、オーバーヘッドが低減されます。10G/25G環境で、1コアあたりのパケット処理負荷を低く抑えるためには、まさにこれが必要です。.

なぜRSSは10および25 Gbit/sから重要になるのか

1 Gbit/sの場合、多くの場合、単一のコアパケット負荷ですが、10 Gbit/sを超えるとバランスは急速に崩れます。小さなパケットはPPS値を上昇させ、その結果、コアがすぐに100％の負荷に達し、パケットドロップが発生します。まさにその時点で、RSSは利用可能な帯域幅を倍増させるような働きをします。私は負荷を複数のコア, 、コンテキスト切り替えを減らし、レイテンシ曲線をより安定させます。その結果、クリーンなRSSが確保されて初めて、実際のスループットがリンクレートに近づきます。.

LinuxサーバーでのRSSの設定

Linuxでは、RSSの操作は主に エスツール, 、ドライバオプション、およびsysfsを設定し、NICの機能を確実に有効にします。まず、最大RXチャネル数を取得し、次にCPUに適したキュー数を設定します。続いて、TCP/UDP、および必要に応じてVLANやトンネリングのRSSハッシュを確認し、負荷プロファイルが適切に分散されるようにします。割り込み分散のバックグラウンドノイズについては、 IRQバランシング, 、とはいえ、重要なキューは手動でピン留めする方が好きですが。そこで、私は次のように連携させています キュー ホストのトポロジーに密接に適合し、不要な移動を防ぐ。.

間接参照テーブル、RSSキー、ハッシュの微調整：具体的なコマンド

まず、NICの現在の割り当て状況とキーを確認します：

ethtool -x eth0 # 間接テーブル（RXキュー）とRSSキーを表示
ethtool -n eth0 rx-flow-hash tcp4
ethtool -n eth0 rx-flow-hash udp4

クリーンで均一な分散を実現するため、間接テーブルを希望するキュー数に設定します。キューが16個の場合は、均等なマッピングを選択します：

ethtool -X eth0 equal 16  # を 16 つのキューに均等に分散

必要に応じて、ハッシュフィールドを調整します。4-タプル（s=送信元IP、d=宛先IP、f=送信元ポート、n=宛先ポート）を使用するTCP4の場合：

ethtool -N eth0 rx-flow-hash tcp4 sdfn
ethtool -N eth0 rx-flow-hash udp4 sdfn
ethtool -N eth0 rx-flow-hash tcp6 sdfn
ethtool -N eth0 rx-flow-hash udp6 sdfn

一部のドライバでは、独自のRSSキーを設定することも可能です（例えば、特殊なケースで配信範囲を広げるためなど）：

ethtool -X eth0 hkey   # （ドライバ／NICがこれをサポートしている場合のみ）

CPUアフィニティとNUMAを正しく設定する

各RXキューを以下のようにマッピングしています。 IRQアフィニティ 専用コアに割り当て、その際NUMAを考慮して、データがメモリコントローラを経由する距離を短くします。NICがノード0で動作している場合、メインキューもノード0のコアにバインドし、ワークロードをその近くに配置します。この近接性により、遠隔アクセスが減少し、メモリレイテンシが大幅に低減されます。この際、本番用キューのプロファイルや、管理タスクとオフロードタスク用にコアを分離しておくことが有効です。さらに詳細な設定を行いたい場合は、微調整に関するヒントが以下に記載されています。 IRQアフィニティ, 計画についてはコア簡素化された。

IRQアフィニティ・プレイブック：IRQから安定したコアバインディングへ

まず、どのIRQがRXキューに割り当てられているかを特定し、それらを固定します：

grep -E "eth0.*Rx" /proc/interrupts
cat /sys/class/net/eth0/device/numa_node

この割り当ては、以下のように設定します。 smp_affinity_list, 、そうすればヘックスマスクを計算する必要がなくなる。例：RXキュー0～7をコア2～9に割り当てる場合：

# 例：IRQをコア2～9に割り当てる（IRQごとに1行）
echo 2  > /proc/irq//smp_affinity_list
echo 3  > /proc/irq//smp_affinity_list
echo 4  > /proc/irq//smp_affinity_list
...
echo 9  > /proc/irq//smp_affinity_list

重要：各キューが独自の割り込みを持つためには、MSI-Xが有効になっている必要があります。手動ピンニングを使用する場合、私は イラクバランス これらのIRQに対して（例：ブラックリストによる）対応を行うか、静的レイアウトのホストではそのサービスを個別に無効にしてください。NUMAについては、さらに以下のコマンドでチェックします。 lscpu そして、クロスノードパスが生成されないように、PCIeの割り当ても調整します。.

ハッシュの設定とプロトコル

ハッシュフィールドは、実際の トラフィック- トラフィックを特定の少数のキューに集中させるのではなく、広く分散させる。TCP/UDPでは4タプルを使用し、IPv6でも同様の方法を採用しているが、VXLANやGREの場合はカプセル化の追加フィールドも考慮に入れる。一部のNICには設定可能なハッシュキーが用意されており、私はこれを主要なワークロードに合わせて調整しています。個々のキューに負荷の集中が見られた場合は、直ちにハッシュの選択を再調整します。この作業にかかる時間はわずかですが、これにより 経営難 接続数が多い場合。.

割り込みコアリセシングとPPS

私はRSSを適度に組み合わせています 割り込み合体, 、PPS負荷の高いトラフィックを処理しやすいバッチにまとめるためです。これにより割り込みオーバーヘッドは低減されますが、遅延に敏感なサービスのパフォーマンスを低下させてはなりません。そのため、往復時間を測定し、コアリセシングの値を段階的に調整しています。ストレージやバックアップの負荷を処理する場合は、L7 API や VoIP の場合よりも、より明確にバッチ化を行うことができます。総じて、私はバランスを調整しています レイテンシー スループットを調整し、両者が一致するまで。.

実務におけるコアレッシング：プロファイルと測定ポイント

まずは適度なデフォルト設定から始め、ワークロードごとに最適な設定を探っていきます。実績のある3つの初期プロファイル：

API/低遅延： rx-usecs 2～6, rx-frames 16–32, 適応型をオフに
オールラウンド： rx-usecs 8～16, rx-frames 32–64, 適応型
バルク／ストレージ： rx-usecs 24～48, rx-frames 128–256, 適応型

ethtool -c eth0
ethtool -C eth0 rx-usecs 12 rx-frames 64 adaptive-rx on

その際、p95/p99レイテンシ、PPS、コアごとのCPU負荷、および再送信回数を測定しています。APIやVoIPで変動の拡大が見られた時点で、私は rx-usecs 再び下げる。ストレージに関しては、割り込みを節約するために、フレーム単位でスケールアップする傾向がある。.

10 Gbit環境におけるRSS

10G NICでは、たいてい8～16で作業しています キュー ポートごとに、CPUが十分なコア数を確保できる限り。これにより、Webサーバー、ストレージゲートウェイ、仮想化ホストは、多数の並列接続においてもスムーズにスケーリングします。メインキューを空きコアに割り当て、その後、PPS、レイテンシ、および再送信回数を測定します。パケットドロップが発生した場合は、コアリセシング、ハッシュ、および各キューの利用率を確認します。その後、 親和性, 、負荷が均一になるまで。.

25 Gbitおよびマルチ25G構成におけるRSS

25 Gbit/sになるとPPSとバス負荷が増加するため、私は NUMA- 意識を高め、キューやオフロードを十分に考慮する。アプリケーションが許容する限り、Large Receive Offload（LRO）やRSCを利用することで、スタックへのパケット負荷を軽減できる。また、ネットワーク以外のボトルネックを排除するため、PCIeレーンも確認する。複数の25Gリンクを持つホストでは、タスクやノードごとにキューとアフィニティを厳格に分離しています。具体的には、次のようにしています。 帯域幅 かつ、クロスノードトラフィックに巻き込まれることなく、コアを効率的に処理する。.

ハードウェア／ドライバーの詳細：私が注意している点

すべてのNICの挙動が同じというわけではありません。Intelの各世代（例：ixgbe、i40e、ice）には、フローを特定のキューに紐付ける「Flow Director/ATR」といった機能が搭載されており、ホットスポットを平準化したい場合に役立ちます。 Mellanox mlx5はハードウェアでaRFSをサポートしており、スタックが多数のソケットを処理する場合にCPU負荷を軽減します。私はケースバイケースでこれらの機能を有効にするかどうかを判断し、それによって負荷分散が改善されるかどうかを測定しています。ルーティング／NATシステムでは、ヘッダーの一貫性を維持するためにLROを無効にし、GROを採用することがよくあります。一方、純粋なサーバーワークロードでは、LRO／GROがPPSの負荷を緩和するのに役立ちます。また、キューごとに十分な数のMSI-Xベクトルを確保し、ファームウェアを正しいバージョンに保つことも重要です。.

仮想化とコンテナにおけるRSS

ハイパーバイザー内では、物理的な RSS- ゲストが人為的なボトルネックに直面しないよう、virtio-net などマルチキュー対応の vNIC を使用してキューを構成します。 VMのCPUピンニングに注意を払い、物理NICとのvCPU-NUMA近接性を設定しています。これにより、データはローカルに留まり、ホストのメモリアクセスにかかる負荷が軽減されます。コンテナについては、重要なPodを適切なコアに割り当て、ホストキューに不要な負荷がかからないようにしています。この構成により、 効率性 マイクロサービスでは、多くの小さなフローが発生します。.

SR-IOVとVF-RSSを正しく活用する

SR-IOV を使用すると、VM に独自の VF を割り当てることができ、各 VF はさらに複数のキューと RSS を提供できます。ポートごとに十分な数のVFを割り当て、MSI-Xの容量に注意を払い、VM内のvCPU数に合わせてVFのIRQをピン割り当てします。Linuxゲストでは、マルチキューを明示的に有効にします。そうしないと、vNICが単一キューのままになることが多いためです：

ゲスト上の #（virtio-net の例）
ethtool -l eth0
ethtool -L eth0 combined 4

複数の仮想ディスク（VF）を持つホストについては、VM同士が同じ物理受信パス上で互いに干渉しないよう、NUMAノードおよびワークロードごとに厳密に分散させています。.

モニタリングとトラブルシューティング

私は各々の稼働率を監視しています キュー, 、個々のカーネル、パケット損失、再送信などを確認し、不均衡を早期に検知します。あるカーネルが処理を開始しても他のカーネルが空き状態のままの場合、アフィニティやキュー数が適切でないことがよくあります。そのような場合は、ハッシュフィールド、IRQマスク、コアレッシング値を順に確認します。さらに、以下の点も確認します。 SoftIRQの負荷, 、それは排他効果の兆候を示しているからです。これらの兆候が安定しているように見えて初めて、トラフィックを拡大したり、拡張したりします キュー 続ける。

RPS、RFS、XPS：RSSを補完するソフトウェア

NICのキュー数が少ない場合や、ボンディング／トンネリングを使用する場合は、RSSに以下を追加します。 回転位置検出 (Receive Packet Steering) および RFS (Receive Flow Steering)。RPSはSoftIRQを各コアに分散させ、RFSはフローを、対応するソケットがアクティブになっているコアに紐付けます。私はこれら両方を意図的に有効にします：

# フローエントリのグローバル数を増加させる (RFS)
echo 32768 > /proc/sys/net/core/rps_sock_flow_entries

# RPS用の各RXキューごとのCPU数を設定（例：マスク、適宜調整！）
for f in /sys/class/net/eth0/queues/rx-*/rps_cpus; do echo ffff > "$f"; done

# Pro RXキューのRFS用フローテーブルを設定
for f in /sys/class/net/eth0/queues/rx-*/rps_flow_cnt; do echo 4096 > "$f"; done

TX側では、私は以下を使用しています エックスピーエス (Transmit Packet Steering) により、送信パケットを、そのパケットを生成したコアから送信するようにする：

for f in /sys/class/net/eth0/queues/tx-*/xps_cpus; do echo ffff > "$f"; done

RPS/RFS/XPSは多少CPUリソースを消費しますが、ハードウェア側でキューが不足している場合や、ソケットの局所性を厳密に維持したい場合には役立ちます。.

シングルフロー性能、GRO/TSO、およびビジーポーリング

個々のフローは、当然のことながら1つのコアに紐付けられます。個々のストリームの帯域幅を向上させたい場合は、オフロード（GRO/TSO）、高いコア周波数、そして適切なコアリセシングを活用します。レイテンシが重要なパスについては、 ビジー・ポーリング 役立つ：

# の値を低く設定して測定する
sysctl -w net.core.busy_read=25
sysctl -w net.core.busy_poll=25

ビジーポーリングはコンテキストスイッチを削減しますが、CPU時間を消費します。私はp99レイテンシが重要な場合のみこれを有効にし、全体的な負荷やテールレイテンシへの影響を常に検証しています。 GROについては、サーバーでは通常有効にしていますが、LROは役割に応じて適用しています。ミドルボックスでは、ヘッダー処理やハッシュの一貫性を損なわないよう、保守的な設定に留めています。.

推奨事項と例：キュー、アフィニティ、コマンド

出発点として、以下の条件に合うキューの数を選択します。 CPU 適切であれば、各キューの負荷を観察し、段階的に調整します。10Gの場合は8～16キューで十分なことが多く、25Gの場合は、コア数が確保されている限り、より多くのキューを設定することがよくあります。アフィニティについては、後でパスを分析しやすくするために、IRQごとに明確なマスクを使用しています。以下の表は簡潔な目安を示しており、その後、測定によって検証を行います。測定結果によって初めて、 もっと見る 増やすか、減らすか。.

リンク速度	代表的なRXキュー	コマンドの例	備考
10Gbit/s	8-16	`ethtool -l eth0` \| `ethtool -L eth0 rx 16`	合体適度なレベルに抑え、L7レイテンシを確認する
25 Gbit/s	16–32+	`grep . /proc/interrupts` \| IRQマスクは `エコー`	NUMA 注意：PCIeレーンを確認してください
マルチ-25G	ポートごとに個別に	vNICのマルチキューを有効にする（例：virtio）	コアごとのキューとワークロード分水嶺

これらの目安はあくまで出発点であり、目標ではありません。ワークロードによって状況は大きく異なるからです。私は変更内容を記録し、調整の前後で測定を行い、それ以外の環境設定は変更しないようにしています。システムが本番環境の負荷下でも安定して動作するようになれば、その設定を固定します。その後、カーネルやドライバーのアップデートが行われた際には、再度測定を行います。このようにして、私は RSS 確実に目標に向かって進み、再現性のある結果が得られます。.

よくある課題と対策

少なすぎる キュー 個々のコアに過負荷がかかり、コア数が多すぎると管理負荷が増大し、キャッシュヒット率に悪影響を及ぼします。不適切なアフィニティ設定は、すでに負荷がかかっているコアや誤ったNUMAノードに割り込みを転送してしまいます。また、不適切なハッシュ設定も、支配的なフローがキューを詰まらせる原因となります。私はこれを段階的に解決しています。キューの数を調整し、アフィニティを修正し、ハッシュフィールドを拡張し、コアレッシングを微調整します。変更のたびに、指標, 、それから次のレバーへと進む。.

実務に即したシナリオ

10G対応のストレージサーバーは、8～12の恩恵をすぐに享受できる キュー さらに、バルク転送をスムーズに実行するために、適度なコアレッシングも必要です。接続数が多いAPIサーバーでは、多くの場合、より細かいハッシュフィールドと、割り込み時の低レイテンシが求められます。仮想化ホストは、ゲスト側でvNICマルチキューが有効になっており、ホストのレイアウトに合致している場合に、著しいパフォーマンス向上を実現します。コンテナワークロードは、重要なポッドがNICやNUMAメモリの近くで実行されるほど、よりスムーズに動作します。私は状況に応じて、以下の方法でこれらのパターンを拡張しています。 ピーピーエス, 、再送信およびキューの分散を比較する。.

高性能なプラットフォームという強み

一貫して設定されたホスティング環境 RSS, 、マルチキューNIC、および適切なアフィニティ設定は、ピーク負荷時に顕著な余力をもたらします。サーバーサービスを評価する際は、マルチキュー機能、NUMAピンニング、およびモニタリングについて具体的に確認すべきです。これらの点を明確に実装しているプロバイダーは、多くの場合、著しく優れたスループット曲線を実現しています。高性能なサーバーおよびホスティングソリューションについては、webhoster.deを強くお勧めします。この方針は、 パフォーマンス 特に多数の並列フローがある場合、安定性を発揮します。.

実践のためのまとめ

起動させる 受け取る サイドスケーリングを行い、適切なキュー数を設定し、IRQを適切なコアに割り当て、ハッシュ設定を確認します。その後、レイテンシを低減するためにコアリセシングを最適化し、NUMAの近接性に注意を払い、ワークロードを一貫して分散させます。仮想化環境では、ゲスト内までマルチキューを活用し、ピンニングとアフィニティを同期させます。PPS、キュー負荷、再送信、レイテンシに関する測定結果に基づいて、次のステップを決定します。このように進めれば、10Gおよび25Gの性能を実際に引き出し、 レイテンシー その枠組みの中で、確実にネットワーク効果を得ることができます。.