受信側スケーリングはホームサーバーのネットワーク負荷をどのように分散させるのですか？
受信側スケーリング（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ハブ
もっと読む
ホームAIサーバーはどのようにして各ユーザーのコンテキストを分離しているのですか？
ホームAIサーバーは同じモデルを共有しながら各ユーザーのコンテキストを分離できますが、その分離はモデル自体から生じるものではありません。チャット、メモリー記録、取得したドキュメント、キャッシュエントリ、ツール呼び出しのすべてを認証済みユーザーに紐付けてから、その情報がプロンプトに届くようにすることから生まれます。 二人が別々にサインインできるのに、一方のユーザーの質問が他方のメモを取得してしまう場合、その失敗は通常モデルの周辺のアプリケーションにあります。重要なテストは、アイデンティティがリクエストの全経路で保持されているかどうかです。この記事はその経路をたどり、どこで分離を強制すべきか、どこでよく破られるか、そしていつより強い境界が必要かを示します。 モデルは共有できても、個人のコンテキストは共有できません モデルの重みは共通の推論エンジンです。モデルが通常の推論リクエストを処理している場合、家族や同僚ごとに別々のコピーを用意する必要はありません。分けておくべきは、その重みの周りに特定のリクエストのために組み立てられた情報です。 その情報には、現在のチャット、保存された会話履歴、ユーザーの設定、取得したファイルの抜粋、ベクター検索の結果、ツールの出力、一時キャッシュ、認証情報が含まれます。これらの層が組み合わさって個人のコンテキストを形成します。同じモデルプロセスを通しても、異なるユーザーには異なるコンテキストパッケージが提供されるべきです。 この区別により、アーキテクチャは実用的になります。ホームサーバーは複数の同一モデルのコピーを読み込むことを避けつつ、各アシスタントを個別化するデータの分離を維持できます。分離の境界は、アイデンティティ、ストレージ、検索、セッション、ツールアクセスにあり、単にモデルにプライバシーを尊重するよう指示するプロンプトにはありません。 アイデンティティはリクエストの全過程にわたって追跡されなければなりません 別々のログイン画面は最初のステップに過ぎません。認証はリクエストを行う人物を確定し、認可はその人物がアクセスできるチャット、ファイル、メモリー、アクションを決定します。効果的な分離には、ユーザーがインターフェースを開くときだけでなく、すべてのデータ境界で認証後の認可が必要です。 サーバーは、検証済みのセッションまたはアクセストークンから安定したユーザーIDを導き出すべきです。フォームフィールド、URLパラメーター、チャットメッセージで送信されたユーザーIDを信用してはいけません。そうしないと、クライアントが制御する値を一つ変更するだけで、他人の記録を要求できてしまう可能性があります。 そのサーバー由来のIDはすべてのルックアップの一部となります。会話クエリ、ベクター検索、ファイルパス、キャッシュキー、ツールの認証情報はすべて同じ信頼されたユーザースコープを必要とします。下流のサービスの1つがこれを失うと、フロントエンドは別々のアカウントを表示していても、システムは静かに共有コンテキストに戻ってしまいます。 耐久メモリにはストレージレベルの境界が必要です 長期メモリは通常、リレーショナルデータベース、ドキュメントストア、またはディスク上のファイルに保存されます。各レコードには所有者またはテナント識別子が必要で、すべての読み取り、更新、削除はそのIDに制限されなければなりません。広範なクエリでデータが返された後にフィルタリングするのは遅すぎます。 データベースポリシーは、アプリケーションコードの下に第2の強制ポイントを提供できます。データベースがレコードを返す前に現在のユーザーを評価すると、1つのアプリケーションルートでフィルターが漏れてもクロスユーザーの情報漏洩になる可能性が低くなります。 ファイルベースのメモリも同じ規律が必要です。各ユーザーに専用のディレクトリを割り当て、所有権とアクセス制御ルールを維持し、アプリケーションが認証済みのIDからパスを解決するようにします。ブラウザから提供されたフォルダ名は認可の境界ではなく、無制限のファイルシステムアクセスを持つ共有サービスアカウントは慎重に設定されたディレクトリを回避できます。 プロンプトが構築される前に取得は範囲を限定する必要があります RAGは最も重要な分離ポイントの一つを作り出します。なぜなら、取得されたパッセージが直接モデルの作業コンテキストに挿入されるからです。別のユーザーのドキュメントがプロンプトに入った場合、それをモデルに開示しないように頼むのは信頼できる対処法ではありません。まず取得レイヤーで除外しなければなりません。 権限認識型RAGレイヤーは、ドキュメントアクセス権による検索結果のフィルタリングを、パッセージがプロンプトに入る前に行うことができます。認可の判断は、質問で提供されたIDではなく、検証済みのセッションを使用しなければなりません。 ベクターデータベースは、ユーザーごとに1つの名前空間またはコレクションでレコードを分離するか、共有インデックス内で必須のメタデータフィルターを使用して分離できます。分離のための名前空間またはコレクションは、書き込み、検索、削除の範囲を簡単にし、メタデータフィルタリングは、家庭やチームで共通のドキュメントがある場合の制御された共有をサポートできます。 アプリケーションは検証済みセッションから名前空間を選択すべきであり、プロンプトから受け入れるべきではありません。同じルールはプライベートドキュメントに対してセマンティック検索を行う場合にも適用されます。識別フィルタリングは類似度ランキングの前のクエリパスに属し、結果返却後のクリーンアップステップではありません。 共有ドキュメントにも明示的なモデルが必要です。レコードは1人のユーザー、世帯グループ、またはワークスペースに属することがありますが、そのスコープは権限データとして保存され、一貫して評価されるべきです。ドキュメントを複数の個人インデックスにコピーするのは小規模なシステムでは簡単かもしれませんが、ユーザーや共有フォルダが増えるにつれてグループベースの権限の方が管理しやすくなります。 セッションとキャッシュは誤ってデータを再接続することがあります データベースは完全にフィルタリングできても、キャッシュがコンテキストを漏らすことがあります。チャット履歴が`conversation_id`だけでキャッシュされている場合、衝突や予測可能な識別子を持つ2人のユーザーが同じエントリにアクセスする可能性があります。より安全なキーは信頼されたユーザーIDと会話IDの両方を含みます。 同じ境界はプロンプトキャッシュ、取得チャンクキャッシュ、一時アップロードディレクトリ、メモリ内セッションオブジェクトにも適用されます。テナント認識キャッシュキーは、信頼されたユーザーIDをキャッシュの読み書き両方に渡すことでユーザー間の露出を減らします。 ログアウトは適切な状態を削除または無効化しなければなりません。ブラウザのクッキーをクリアしてもサーバー側のセッション、一時ファイル、またはキャッシュされたプロンプトが残っていると、共有コンピューター上で前のユーザーのコンテキストが露出する可能性があります。期限切れ、削除、アカウント削除は個人データを保持するすべてのストアに伝播すべきです。...
なぜモデルの削除がホームAIサーバーでレイテンシの急増を引き起こすのか？
モデルの追い出しは、ホームAIサーバーに重みを再読み込みさせ、ランタイム状態を再構築させます。コールドスタートを確認し、初回応答の遅延を減らす方法を学びましょう。
NAS移行中にタイムスタンプを最も安全に保持する方法は何ですか？
必要なフィールドを定義し、メタデータ対応のコピー経路をテストし、ソースマニフェストを記録し、コンテンツとメタデータを別々に検証し、切り替え検証が完了するまで古いNASを保持することで、NASのタイムスタンプを保持します。
