受信側スケーリングはホームサーバーのネットワーク負荷をどのように分散させるのですか?

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

受信側スケーリング(Receive-Side Scaling、RSS)は、ホームサーバーのネットワーク負荷を複数のNIC受信キューにハッシュして分散し、それらのキューを異なるCPUコアに割り当てることで負荷を分散します。1つのコアがほぼすべての受信割り込みやプロトコル処理を担当する代わりに、複数のコアが独立した接続を並行して処理できます。

RSSは、サーバーが1つのコアが限界になるほど十分なパケットを受信する場合に最も有効です。単一のディスクを高速化したり、ネットワーク容量を増やしたり、1つの通常のTCPフローをすべてのコアに均等に分割したりするものではありません。RSSの役割は、フローの順序を保ちながらパケット処理のボトルネックを解消することです。

コアの仕組み:複数の受信キューが複数のコアに供給される

マルチキュー受信処理がない場合、高速NICは1つの割り込み経路に対してCPUコアが処理できる速度よりも速く作業を届けてしまいます。全体のCPU使用率は控えめに見えるかもしれませんが、他のコアはアイドル状態で、過負荷のコアでスループットが頭打ちになりネットワーク遅延が増加します。

RSSは複数の受信キューを使用し、受信フローを並行して処理できるようにします。各キューは独自の割り込みと処理経路を生成し、OSが既存のCPUリソースをより多く活用できるようにします。

これは、ファイル共有、メディアストリーム、バックアップ、コンテナアプリを同時に実行するホームサーバーで重要です。これらの独立した接続がRSSに必要な並列作業を提供します。軽負荷の1GbEリンクでは、パケットの圧力が十分でないため違いが見えないこともあります。

フローハッシュは接続を分散しつつ順序を保持する

NICは、送信元・宛先アドレス、ポート、プロトコルなどのパケットヘッダー情報からハッシュを計算します。間接テーブルがそのハッシュを受信キューにマッピングします。同じフローのパケットは通常同じキューに届き、並列処理によるフローの順序の入れ替わりを防ぎます。

RSS、IRQアフィニティ、RPSの関係は、Linux上で実際にどこで処理が行われるかを決定します。ハードウェアRSSは受信キューを選択し、割り込みアフィニティがそのキューをCPUに接続し、ソフトウェアステアリングはハードウェアキューが限られている場合に後続のプロトコル処理を再分配します。

ハッシュは多くのフローを統計的にバランスさせますが、完全ではありません。重いフローが1つのキューに衝突したり、単一の支配的なフローが1つのコアに固定されたままになることもあります。したがって、マルチコアCPUだからといってネットワーク負荷が均等になるとは限らず、コアごとやキューごとの観察がより有用です。

キュー数の増加はボトルネック解消とCPUオーバーヘッドのトレードオフ

キュー数を増やすと並列処理の機会は増えますが、割り込み、スケジューリング作業、キャッシュの移動も増加します。最適なキュー数はNICの性能、CPUのトポロジー、トラフィック量、パケットを消費するアプリケーションが受信処理に近いかどうかによって異なります。

単一コア受信飽和の実例は、総CPU使用率が実際の限界を隠す理由を示しています。実際に役立つテストは、1つのコアが割り込みやsoftirq処理で固定されている一方、他のコアに余裕があるかどうかです。

トラフィックが軽すぎる場合、RSSはオーバーヘッドを増やすこともあります。並列パケット分配はスケールを改善しますが、キューの配置やフローとコアの局所性も効率に影響します。したがって、すべてのキューを有効にすることが万能の最適化ではありません。

RSSがホームサーバーのボトルネックをどう変えるか

RSSは受信経路がCPUボトルネックの場合に効果的です。1つのコアが高いネットワーク処理負荷を示し、複数のクライアントがアクティブで、ストレージにまだ余裕がある場合です。イーサネットリンクが満杯、ディスクが処理を維持できない、暗号化がCPU時間を支配、または1つのアプリケーションがすべてのリクエストを直列化している場合は効果がありません。

観察 考えられる制限 RSSの関連性
1つのコアが忙しく、他のコアはアイドル 受信処理 高い可能性
すべてのコアが低負荷、リンクはラインレート ネットワーク容量 低い
クライアント増加でディスク遅延が上昇 ストレージキュー 間接的にのみ
1つのTCPフローが頭打ち 単一フローまたはアプリケーションの制限 しばしば制限される

NICキューのカウンター、コアごとの割り込み負荷、スループット、アプリケーション遅延を制御された変更の前後で比較してください。より広範なホームサーバーボトルネックチェックは、ネットワーク調整がストレージ、メモリ、計算の制約を隠すのを防ぎます。

よくある質問

RSSは1つのTCP接続をすべてのコアに分割しますか?

通常はしません。RSSは1つのフローのパケットを同じキューに保持し、順序を保ちます。スケーリングの利点は、複数の独立したフローが複数のキューにハッシュされる場合に最も明確です。

1GbEのホームサーバーでRSSは有用ですか?

特に小さなパケットが多い場合や低消費電力CPUの場合は有用ですが、多くのシステムは1つのコアで1GbEを処理できます。RSSを欠けている性能機能とみなす前に、コアごとの負荷を測定してください。

RSSとRPSは同じものですか?

いいえ。RSSはNICハードウェアでパケットを受信キューに振り分け、Receive Packet Steering(RPS)はソフトウェアで関連する分配処理を行います。ハードウェアキュー数が限られている場合、両者は補完し合うことがあります。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.