接続数が多く、小さなパケットのトラフィックが多いギガビットネットワークでの TCP パフォーマンスの向上

解決策 1:

ネットワークカードでの割り込みが多すぎることが問題である可能性があります。帯域幅が問題でない場合、周波数が問題です:

ネットワークカードの送受信バッファを増やします
```
ethtool -g eth0
```

現在の設定 (256 または 512 エントリ) が表示されます。おそらくこれらを 1024、2048、または 3172 に上げることができます。それ以上はおそらく意味がありません。これは、サーバーが着信パケットを十分な速度で処理できない場合にのみいっぱいになる単なるリングバッファーです。

バッファーがいっぱいになり始めた場合、フロー制御は、ルーターまたはスイッチに速度を落とすように指示する追加の手段です:

サーバーとそれが接続されているスイッチ/ルーターポートでイン/アウトバウンドのフロー制御をオンにします。
```
ethtool -a eth0
```

おそらく次のように表示されます:

Pause parameters for eth0:
Autonegotiate:  on
RX:             on
TX:             on

eth0 の現在の設定については、/var/log/messages を確認してください。次のようなものを確認してください:

<ブロック引用>

eth0:リンクは 1000 Mbps、全二重、フロー制御 tx および rx でアップしています

tx と rx が表示されない場合は、ネットワーク管理者がスイッチ/ルーターの値を調整する必要があります。受信/送信フロー制御がオンになっている Cisco。

注意: これらの値を変更すると、リンクが非常に短時間 (1 秒未満) ダウンおよびアップします。

それでも解決しない場合は、ネットワークカードの速度を 100 MBit に下げることもできます (スイッチ/ルーターポートで同じことを行います)。
```
ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
```

しかし、あなたの場合は、NIC リングバッファの受信バッファを増やしてください。

解決策 2:

以下は決定的な答えではないかもしれませんが、間違いなくいくつかのアイデアを提示します

これらを sysctl.conf に追加してみてください

##  tcp selective acknowledgements. 
net.ipv4.tcp_sack = 1
##enable window scaling
net.ipv4.tcp_window_scaling = 1
##
net.ipv4.tcp_no_metrics_save = 1

選択的 tcp ack は、高帯域幅ネットワークの場合に最適なパフォーマンスを得るのに適しています。ただし、他の欠点にも注意してください。ここでは、ウィンドウスケーリングの利点について説明します。 3 番目の sysctl オプションについて:デフォルトでは、TCP は接続が閉じるときにさまざまな接続メトリックをルートキャッシュに保存するため、近い将来確立される接続はこれらを使用して初期条件を設定できます。通常、これにより全体的なパフォーマンスが向上しますが、パフォーマンスが低下する場合があります。設定されている場合、TCP は接続を閉じるときにメトリックをキャッシュしません。

で確認してください

ethtool -k ethX

オフロードが有効かどうかを確認します。 TCP チェックサムオフロードとラージセグメントオフロードは、今日のイーサネット NIC の大半でサポートされており、Broadcom もサポートしているようです。

ツールを使ってみる

powertop

ネットワークがアイドル状態で、ネットワークが飽和状態に達したとき。これは、NIC 割り込みが原因であるかどうかを明確に示します。デバイスポーリングは、このような状況に対する答えです。 FreeBsd は ifconfig 内でのポーリングスイッチをサポートしていますが、Linux にはそのようなオプションがありません。ポーリングを有効にするには、これを参照してください。 BroadCom もポーリングをサポートしているとのことですが、これは朗報です。

トラフィックがほとんど小さなパケットで構成されていると述べたので、ジャンボパケットの微調整はあなたのためにそれをカットしないかもしれません.とにかく試してみてください!

解決策 3:

微調整のリストで、タイムスタンプがオフになっていることに気付きました。そうしないでください。これは、帯域幅が非常に高価であり、人々がパケットあたり数バイトを節約したいと考えていた時代への古い逆戻りです。たとえば、「CLOSE_WAIT」でソケットに到着するパケットが接続の古いパケットであるか、新しい接続の新しいパケットであり、RTT 計算に役立つかを伝えるために、最近の TCP スタックによって使用されます。そして、タイムスタンプのために数バイトを節約することは、IPv6 アドレスが追加しようとしているものと比較して何もありません.タイムスタンプをオフにすることは、良いことよりも悪いことです。

タイムスタンプをオフにするためのこの推奨事項は、ある世代から次の世代のシステム管理者に受け継がれ続ける単なる逆戻りです。一種の「都市伝説」的なものです。

解決策 4:

すべての CPU コアに負荷を分散する必要があります。「irqbalance」を開始します。

解決策 5:

私の場合、チューニングは 1 つだけです:

net.ipv4.tcp_timestamps = 0