기가비트 본드가 최소 150MB / s의 처리량을 제공하지 않는 이유는 무엇입니까?

두 개의 서로 다른 PCIe 어댑터에서 두 개의 PowerEdge 6950 크로스 오버 (직선 사용)를 직접 연결했습니다.

이러한 각 라인에서 기가비트 링크를 얻습니다 (1000MBit, 전이중, 양방향 양방향 제어).

이제 양쪽에서 rr 알고리즘을 사용하여 이러한 인터페이스를 bond0에 연결하려고합니다 (단일 IP 세션에 대해 2000MBit을 얻고 싶습니다).

tdd 모드에서 dd bs = 1M 및 netcat을 사용하여 / dev / zero를 / dev / null로 전송하여 처리량을 테스트하면 150MB / s 이상이 아닌 70MB / s의 처리량을 얻습니다.

단일 라인을 사용할 때 각 라인에 다른 방향을 사용하면 각 라인에 약 98MB / s가 표시됩니다. 단일 회선을 사용할 때 트래픽이 "동일한"방향으로 진행되면 회선에서 70MB / s 및 90MB / s를 얻습니다.

bond-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로 변경했습니다.

다시 결합한 후 약 100MB / 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.6GB) 복사, 35.8489 초, 240MB / s

많은 tcp / ip 및 저수준 드라이버 옵션을 변경했습니다. 여기에는 네트워크 버퍼의 확대가 포함됩니다. 이것이 dd이제 200MB / 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

본드 장치의 특수 설정 (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 동기화의 속도를 높이려는 비슷한 문제가있었습니다. 결국 나는 약 150MB / 초의 동기화 속도를 얻었습니다. 이들은 두 노드에 적용한 설정입니다.

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

당신은 또한 당신이 이미 (로 네트워크 카드를 가지고 있지 않은 경우 인터럽트 유착을 가능하게 시도 할 수 ethtool을 --coalesce )

스위치에서이 양방향 트렁크를 구성 했습니까? 그렇지 않으면 그렇게 작동하지 않습니다. 액티브 / 패시브 모드에서만 작동하고 1Gbps 링크 중 하나만 사용합니다.

PowerEdge 6950은 전체 버스에서 공유되는 최대 133MB / s의 PCI 슬롯으로 제한됩니다. 시스템 버스 아키텍처 자체에 I / O 제한이있을 수 있습니다.

테스트 할 하드웨어 및 I / O 아키텍처가 다른 다른 시스템을 사용하는 것 외에도 케이블 연결도 가능합니다. 일부 가능한 조합은 길이뿐만 아니라 다른 등급 (5e 대 6)의 선을 따라있을 수 있습니다 (짧은 것이 항상 더 좋은 것은 아닙니다).

점보 프레임?

ifconfig <interface> mtu 9000

스위치와 닉스가 지원하는 한 점보 프레임을 사용하는 것은 큰 도움이됩니다. 비 관리 형 siwtch가있는 경우 대역폭에 대해 원하는 곳을 얻지 못할 가능성이 높지만 스위치에서 포트를 함께 바인딩하는 경우에는 해당되지 않습니다. 여기에 오래 전에 배운 것이 있는데, 65 %의 시간, 물리적 인 문제입니다. cat6 케이블을 사용하고 있습니까?

당신이 당신의 nics에 점보 프레임을 구성했다면 그것의 모양으로 당신은 높은 MTU를 지원하도록 스위치를 구성했는지 확인하십시오.

점보 프레임은 기가비트 네트워크에서 뛰어난 성능을 제공하지만 끝과 끝 (소스 및 대상 서버와 네트워크 스위치 모두)을 구성했는지 확인해야합니다.