Linuxはプロセス間でどのように帯域幅を割り当てますか？
トラフィックシェーピングを設定しない場合、Linuxはプロセス間で（送信）帯域幅をどのように割り当てますか？
私の特定の状況は、クラウドVMで30の同じプロセスを実行していることです。各プロセスは基本的にネットワーク（TCP）を介して可能な限り高速にデータを送信しています。一緒に彼らは私が期待する総発信帯域幅をヒットするようです。ただし、一部のプロセスは他のプロセスよりもはるかに早く完了し、より多くの帯域幅を消費します（最大3倍）。高速プロセスが完了すると、残りのプロセスが高速化し、より多くの帯域幅を使用します。
Linuxは、各プロセスが取得する必要がある帯域幅をどのように決定しますか？
ほとんどのパフォーマンス問題と同様に、それは複雑です。各タスクが取得する帯域幅は、ネットワークスタックのさまざまな層での多くのものの間の複雑な相互作用です。形を整えなくても。不完全なリスト：
- タスク（およびドライバー割り込みハンドラー）がCPUにアクセスできる場合のCPUスケジューラー
- タスクがデータを取得する速度。ボトルネックや競合によって制限される可能性があります
- 使用されているキューイング規則、基本的にはパケットスケジューラ
- ハードウェアTXキューの数やフローの選択方法などのドライバーの詳細
- TCPプロトコルの動作、1つのフローが輻輳制御にヒットした場合、帯域幅が制限されている間、フローが遅くなる可能性があります
- フローを受信するリモートシステムに関する上記のすべての考慮事項
- すべての接続が同じ受信者に向けられていない場合、otherエンドはyourエンドよりも影響が大きい可能性があります
これらの多くは、同等の帯域幅「フェアネス」ではなく、他の基準を最適化していません。 TCP輻輳制御は、輻輳による崩壊に苦しむのではなく、むしろ良い利益をもたらすでしょう。
そして、忘れないでください、あなたはおそらくが常にある唯一のネットワークではありません-したがって、ルーターやスイッチなども考慮に入れる必要があります「ここ」と「そこ」の間。
これが好奇心以上のものである場合、可能な限り高速な解決策は、より多くの帯域幅を取得することです。
または、QoS、シェーピング、またはアプリケーションスロットリングを実行すると、より適切な方法であれば、全体的な動作を改善するためにクォータを設定できます。しかし、これはもはや最速ではありません。ポリシーによって勝者と敗者を選択します。
複数の車線がある混雑しているが完全に停滞していない高速道路では、実際には一部の車や車線が一時的に他の車よりも速いことに気づきましたか？車の流れを明示的に制御してこれらに「帯域幅」を割り当てる人はいません。同様に、Linuxはプロセス間で帯域幅を明示的に割り当てていません。
目に見えるのは、主にTCPフローとさまざまなTCP=接続間のフローと輻輳制御の相互作用です。共有リソースが不足している場合、一時的な勝者と敗者が複数のエージェントがこれらのリソースのいくつかを獲得するために戦います。
多くは、「プロセスごとに設定および変更できる」「ナイス」係数と、現在実行中の他のすべてのプロセスの「ナイス」係数、使用可能なCPUの数、および「フロント」バスの速度に依存します。 「バック」バス、データバスなど