ギガビットボンドが150 MB / s以上のスループットを提供しないのはなぜですか？

2つの異なるPCIeアダプターに2つのPowerEdge 6950クロスオーバーを（直線を使用して）直接接続しました。

これらの各回線（1000 MBit、全二重、両方向のフロー制御）でギガビットリンクを取得します。

今、私は両側のrrアルゴリズムを使用してこれらのインターフェイスをbond0に結合しようとしています（単一のIPセッションで2000 MBitを取得したい）。

tddモードでdd bs = 1Mとnetcatを使用して/ dev / zeroを/ dev / nullに転送してスループットをテストすると、予想通り150 MB / sを超える-70 MB / sのスループットが得られます。

単一の回線を使用する場合、各回線で異なる方向を使用すると、各回線で約98 MB /秒になります。単一の回線を使用する場合、トラフィックが「同じ」方向に進むと、回線で70 MB /秒と90 MB /秒になります。

bonding-readme（/usr/src/linux/Documentation/networking/bonding.txt）を読んだ後、次のセクションが有用であることがわかりました：（13.1.1シングルスイッチトポロジのMTボンディングモードの選択）

balance-rr：このモードは、単一のTCP / IP接続が複数のインターフェースにトラフィックをストライプ化することを許可する唯一のモードです。したがって、単一のTCP / IPストリームが複数のインターフェイスの価値のあるスループットを利用できるようにする唯一のモードです。ただし、これにはコストがかかります。ストライピングにより、多くの場合、セグメントを再送信することにより、ピアシステムがパケットの順序を乱し、TCP / IPの輻輳制御システムが作動します。

    It is possible to adjust TCP/IP's congestion limits by
    altering the net.ipv4.tcp_reordering sysctl parameter. The
    usual default value is 3, and the maximum useful value is 127.
    For a four interface balance-rr bond, expect that a single
    TCP/IP stream will utilize no more than approximately 2.3
    interface's worth of throughput, even after adjusting
    tcp_reordering.

    Note that this out of order delivery occurs when both the
    sending and receiving systems are utilizing a multiple
    interface bond.  Consider a configuration in which a
    balance-rr bond feeds into a single higher capacity network
    channel (e.g., multiple 100Mb/sec ethernets feeding a single
    gigabit ethernet via an etherchannel capable switch).  In this
    configuration, traffic sent from the multiple 100Mb devices to
    a destination connected to the gigabit device will not see
    packets out of order.  However, traffic sent from the gigabit
    device to the multiple 100Mb devices may or may not see
    traffic out of order, depending upon the balance policy of the
    switch.  Many switches do not support any modes that stripe
    traffic (instead choosing a port based upon IP or MAC level
    addresses); for those devices, traffic flowing from the
    gigabit device to the many 100Mb devices will only utilize one
    interface.

ここで、すべての回線（4）で接続された両方のサーバーのパラメーターを3から127に変更しました。

再度結合した後、約100 MB / sを取得しますが、それでもそれ以上ではありません。

なぜアイデアがありますか？

更新：ハードウェアの詳細lspci -v：

24:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
        Subsystem: Intel Corporation PRO/1000 PT Dual Port Server Adapter
        Flags: bus master, fast devsel, latency 0, IRQ 24
        Memory at dfe80000 (32-bit, non-prefetchable) [size=128K]
        Memory at dfea0000 (32-bit, non-prefetchable) [size=128K]
        I/O ports at dcc0 [size=32]
        Capabilities: [c8] Power Management version 2
        Capabilities: [d0] MSI: Mask- 64bit+ Count=1/1 Enable-
        Capabilities: [e0] Express Endpoint, MSI 00
        Kernel driver in use: e1000
        Kernel modules: e1000

最終結果の更新：

8589934592バイト（8.6 GB）コピー、35.8489秒、240 MB / s

多くのtcp / ipおよび低レベルドライバーのオプションを変更しました。これには、ネットワークバッファの拡大が含まれます。これがdd、200 MB / sを超える数値を表示するようになった理由です。（送信バッファーで）転送を待機している出力がまだある間にddは終了します。

更新2011-08-05：目標を達成するために変更された設定（/etc/sysctl.conf）：

# See http://www-didc.lbl.gov/TCP-tuning/linux.html
# raise TCP max buffer size to 16 MB. default: 131071
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# raise autotuninmg TCP buffer limits
# min, default and max number of bytes to use
# Defaults:
#net.ipv4.tcp_rmem = 4096 87380 174760
#net.ipv4.tcp_wmem = 4096 16384 131072
# Tuning:
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# Default: Backlog 300
net.core.netdev_max_backlog = 2500
#
# Oracle-DB settings:
fs.file-max = 6815744
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
kernel.shmmax = 2147659776
kernel.sem = 1250 256000 100 1024
net.core.rmem_default = 262144
net.core.wmem_default = 262144
#
# Tuning for network-bonding according to bonding.txt:
net.ipv4.tcp_reordering=127

bond-deviceの特別な設定（SLES：/ etc / sysconfig / network / ifcfg-bond0）：

MTU='9216'
LINK_OPTIONS='txqueuelen 10000'

可能な限り最大のMTUを設定することがソリューションの鍵であったことに注意してください。

関連するネットワークカードのrx / txバッファーのチューニング：

/usr/sbin/ethtool -G eth2 rx 2048 tx 2048
/usr/sbin/ethtool -G eth4 rx 2048 tx 2048

しばらく前に、2つのギガビットリンクでdrbd同期の速度を上げようとすると、同様の問題が発生しました。最終的に、同期速度は約150MB /秒になりました。これらは両方のノードに適用した設定です。

ifconfig bond0 mtu 9000
ifconfig bond0 txqueuelen 10000
echo 3000 > /proc/sys/net/core/netdev_max_backlog

ネットワークカードをまだ持っていない場合は、割り込み合体を有効にすることもできます（ethtool --coalesceを使用）

スイッチでこの双方向トランクを構成しましたか？そうでない場合は、そのようには動作しません。アクティブ/パッシブモードで動作し、1Gbpsリンクの1つだけを使用します。

PowerEdge 6950は、バス全体で133 MB / sで共有されるPCIスロットに制限されているようです。システムバスアーキテクチャ自体にI / Oの制限があります。

テストするハードウェアとI / Oアーキテクチャが異なる他のシステムのほかに、ケーブル配線も同様に機能する可能性があります。いくつかの可能な組み合わせは、異なる評価（5e対6）と長さの線に沿っている場合があります（短いほど良いとは限りません）。

ジャンボフレーム？

ifconfig <interface> mtu 9000

ジャンボフレームを実行することは、スイッチとNICがそれをサポートしている限り、非常に役立ちます。管理されていないsiwtchがある場合、帯域幅に必要な場所を取得できない可能性が高くなりますが、スイッチでポートを一緒にバインドする場合はそうではありません。ここに、私がずっと前に学んだ、65％の時間の物理的な問題があります。cat6ケーブルを使用していますか？

NICでジャンボフレームを設定している場合は、見た目でスイッチが高MTUをサポートするように設定されていることを確認してください。

ジャンボフレームは、ギガビットネットワーク上で優れたパフォーマンスを発揮しますが、エンドツーエンド（送信元サーバーと送信先サーバー、およびそれらが使用するネットワークスイッチの両方）を確実に構成する必要があります。