web-dev-qa-db-ja.com

ジャンボフレームが有効になっているとフルMTUが使用されない

ジャンボフレームを有効にすることでメリットが得られるかどうかをテストしてきました。 XeonクアッドコアE3122CPU、8GのRAMおよびBroadcomNetXtreme IIBCM5716ギガビットイーサネットカードを搭載した2台の同一のDellR210サーバーをセットアップしました。bnx2ネットワークドライバーをオンにしてDebianSqueezeを実行しています両方のシステム。サーバーは、プライベートサブネット上の一方のNICに接続されており、SSHと両方にもう一方のNIC監視：私が知っているOSチューニングパラメータを追加しました：

sysctl -w net.core.rmem_max=134217728             
sysctl -w net.core.wmem_max=134217728             
sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"  
sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"  
sysctl -w net.core.netdev_max_backlog=300000  
sysctl -w net.ipv4.tcp_sack=0  
sysctl -w net.ipv4.tcp_fin_timeout=15  
sysctl -w net.ipv4.tcp_timestamps=0    
ifconfig ethX txqueuelen 300000  
ethtool -K eth1 gso on

Ethtool -k出力は示しています

rx-checksumming: on  
tx-checksumming: on
scatter-gather: on   
tcp-segmentation-offload: on  
udp-fragmentation-offload: off  
generic-segmentation-offload: on  
generic-receive-offload: on  
large-receive-offload: off  
ntuple-filters: off  
receive-hashing: off

両方のサーバーは、ifconfigを介して9000バイトのジャンボフレーム用に構成されています（Sudo /sbin/ifconfig eth1 mtu 9000）そして私はpingを介して両方のシステムのMTUを確認しました（ping -s 8972 -M do <other IP>）。 netperfを使用して一括転送をテストすると、tcpdumpは、データパケットの大部分がフレームサイズ9014で9000バイトの完全なMTUを使用していることを確認します。

ただし、「実際の」アプリケーションでテストする場合、一方のサーバーにPostgresを設定し、もう一方をクライアントとして使用すると、結果セットがメガバイトに達する非常に大きな選択の場合でも、tcpdumpとtsharkによって報告される最大MTUは2160です。 iproute2を使用してルートにadvmssを設定するなどのいんちきを試したにもかかわらず、それを高くすることができません。

考え？

TIA。

linuxnetworkingethernetmtujumboframes
3
sevenr

Postgresは、ジャンボフレームを完全にパックするための最良の「実際の」アプリケーションではない可能性があります。 古いリストスレッド に基づくと、開発者はTCP_NODELAYやTCP_CORK（Nagleアルゴリズムを無効にする）を使用してパフォーマンスを改善しようとしたようです。

次のような別のアプリケーションを使用してみてください...

  • HTTP（1つのホスト上のWebサーバー、他のサーバー上の大きなファイルをプルする）
  • NFS（ "rsize = 8192、wsize = 8192"でマウント）
  • SOAPを使用してpostgresデータを公開する
  • MySQL、DB2 Express、Oracle XE、Sybase Anywhere（4kパケット以上）をお試しください。他のデータベースが同じテーブル、データ、クエリでジャンボパケットをより適切に満たす場合は、Postgres開発者にバグレポートを提出してください。
1
david