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トラフィックシェーパーを使ったことがある人はいますか？