Почему моя гигабитная связь не обеспечивает пропускную способность не менее 150 МБ / с?

Я напрямую подключил два кроссовера PowerEdge 6950 (используя прямые линии) к двум разным PCIe-адаптерам.

Я получаю гигабитную ссылку на каждую из этих линий (1000 Мбит, полный дуплекс, управление потоком в обоих направлениях).

Теперь я пытаюсь связать эти интерфейсы в bond0 с помощью rr-алгоритма с обеих сторон (я хочу получить 2000 МБит для одного сеанса IP).

Когда я проверил пропускную способность путем перевода / dev / zero в / dev / null с использованием dd bs = 1M и netcat в режиме tcp, я получил пропускную способность 70 МБ / с - нет - как и ожидалось, более 150 МБ / с.

Когда я использую отдельные строки, я получаю около 98 МБ / с в каждой строке, если я использовал другое направление для каждой строки. Когда я использую отдельные линии, я получаю 70 МБ / с и 90 МБ / с на линию, если трафик идет в «том же» направлении.

Прочитав 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 МБ / с, но все равно не больше.

Есть идеи почему?

Обновление: Детали оборудования от 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 ГБ), 35,8489 секунд, 240 МБ / с

Я изменил много опций tcp / ip и low-level-driver. Это включает в себя расширение сетевых буферов. Вот почему ddтеперь отображаются числа, превышающие 200 МБ / с: 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

Специальные настройки для устройства связи (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

У меня была похожая проблема, когда я пытался поднять скорость синхронизации drbd по двум гигабитным каналам. В итоге мне удалось получить скорость синхронизации около 150 МБ / с. Это были настройки, которые я применил на обоих узлах:

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

Вы также можете попытаться включить объединение прерываний, если у вас его еще нет для сетевых карт (с помощью ethtool --coalesce )

Вы настроили эту двустороннюю магистраль на коммутаторе? если нет, то он не будет работать так, он будет работать только в активном / пассивном режиме и использовать только 1 из ссылок 1 Гбит / с.

Похоже, что PowerEdge 6950 ограничен, возможно, слотами PCI, которые достигают 133 МБ / с и распределяются по всей шине. Возможно, вы видите ограничения ввода-вывода для самой архитектуры системной шины.

Помимо тестирования других систем с другим аппаратным обеспечением и архитектурой ввода / вывода, кабели также могут быть задействованы. Некоторые возможные комбинации могут быть в соответствии с различными рейтингами (5e против 6), а также длины (короче не всегда лучше).

Джамбо кадры?

ifconfig <interface> mtu 9000

делать гигантские кадры - гигантская помощь, если ваш коммутатор и ник поддерживают ее. если у вас неуправляемая команда siwtch, скорее всего, вы не получите ничего, что вам нужно для пропускной способности, но это не тот случай, если вы связываете порты на коммутаторе. вот что я узнал давно, в 65% случаев, это физическая проблема. Вы используете кабель Cat6?

если вы сконфигурировали на своих сетевых устройствах jumbo-кадры, которые, по внешнему виду, вы должны убедиться, что вы также сконфигурировали свои коммутаторы для поддержки высокого MTU.

Jumbo-кадры - это отличная производительность в гигабитных сетях, но вы должны убедиться, что вы сконфигурировали их сквозными (как исходный, так и целевой серверы и используемые ими сетевые коммутаторы).