Linuxトラフィック調整(tc)のパフォーマンスボトルネック

Linuxトラフィック調整(tc)のパフォーマンスボトルネック

興味深い質問があります。

Debian StretchがインストールされているLinuxサーバーがあります。サーバーには、単一のCPU E5-2680 v2とIntel 82599ES 10GデュアルポートNICがあります。 HTTPなどの他のサービスは実行されません。

トラフィック調整を有効にするまで、すべてが大丈夫だった。形成規則はhtb qdiscおよびbond0インタフェースで構成されていますbond1

3段階のハッシュフィルタがあります。

  1. 大規模サブネットを選択するための4つのルールフィルタ。ルールは次のとおりです。

    protocol ip u32 ht 800:: match ip src 10.15.0.0/18 hashkey mask 0x0000ff00 at 12 link 1:
    
  2. 大規模サブネットから選択するための60個程度のルールテーブル/24個

    protocol ip u32 ht 1:10 match ip src 10.15.16.0/24 hashkey mask 0x000000ff at 12 link 100:
    
  3. IPに一致する256のルールテーブル

    parent 1:0 prio 100 protocol ip u32 ht 100:20: match ip src 10.15.16.32 flowid 1:20    
    class add dev bond0 parent 1:0 classid 1:1 htb rate 24Gbit ceil 24Gbit burst 4096k cburst 256k
    class add dev bond0 parent 1:1 classid 1:20 htb rate 102400Kbit  burst 4096k cburst 256k    
    qdisc add dev bond0 parent 1:20 pfifo_fast
    

これらのルールを有効にすると、総トラフィックが最大約10Gbpsに達し、ping時間が最大100ms以上になり始めます。しかし、この間、CPU負荷はほぼゼロでした。uptime示された負荷は0.07で、各CPUコアの使用率は約5%に過ぎませんでした。ping成形ルールをクリアするとすぐにOKになりました。

以前は私はこれを使用していて、sfqCPUpfifo_fast負荷がたくさん発生しました。その後、赤に切り替えてCPU負荷なしでより良い結果を得、赤に切り替えてpfifo_fast赤とほぼ同じ結果を得ました。

  • またどんなボトルネックがありますか?
  • 10Gbps以上のネットワークでLinuxトラフィックシェーパーを使ったことがある人はいますか?

関連情報