Dlaczego moja obligacja gigabitowa nie zapewnia przepustowości co najmniej 150 MB / s?

Podłączyłem bezpośrednio dwa zwrotnice PowerEdge 6950 (używając linii prostych) na dwóch różnych adapterach PCIe.

Dostaję łącze gigabitowe na każdej z tych linii (1000 MBit, pełny dupleks, kontrola przepływu w obu kierunkach).

Teraz próbuję połączyć te interfejsy w bond0 za pomocą algorytmu rr po obu stronach (chcę uzyskać 2000 MBit na jedną sesję IP).

Kiedy przetestowałem przepustowość, przesyłając / dev / zero do / dev / null za pomocą dd bs = 1M i netcat w trybie tcp, otrzymuję przepustowość 70 MB / s - nie - zgodnie z oczekiwaniami więcej niż 150 MB / s.

Kiedy używam pojedynczych linii, uzyskuję około 98 MB / s na każdej linii, jeśli użyłem innego kierunku dla każdej linii. Kiedy używam pojedynczych linii, dostaję 70 MB / si 90 MB / s na linii, jeśli ruch idzie w „tym samym” kierunku.

Po przeczytaniu pliku read-bonding (/usr/src/linux/Documentation/networking/bonding.txt) uznałem, że przydatny jest następujący rozdział: (13.1.1 Wybór trybu wiązania MT dla topologii pojedynczego przełącznika)

balance-rr: Ten tryb jest jedynym trybem, który pozwoli pojedynczemu połączeniu TCP / IP na rozłożenie ruchu na wielu interfejsach. Jest to zatem jedyny tryb, który pozwoli pojedynczemu strumieniowi TCP / IP wykorzystać przepustowość większą niż jeden interfejs. Jest to jednak kosztowne: rozkładanie często powoduje, że systemy równorzędne odbierają pakiety w niewłaściwym porządku, powodując uruchomienie systemu kontroli przeciążenia TCP / IP, często przez ponowne przesyłanie segmentów.

    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.

Teraz zmieniłem ten parametr na obu połączonych serwerach we wszystkich liniach (4) z 3 na 127.

Po ponownym związaniu otrzymuję około 100 MB / s, ale nadal nie więcej.

Jakieś pomysły dlaczego?

Aktualizacja: Szczegóły sprzętu od 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

Zaktualizuj końcowe wyniki:

8589934592 bajtów (8,6 GB) skopiowano, 35,8489 sekund, 240 MB / s

Zmieniłem wiele opcji TCP / IP i sterowników niskiego poziomu. Obejmuje to powiększenie buforów sieciowych. Dlatego ddteraz pokazuje liczby większe niż 200 MB / s: dd kończy się, gdy nadal oczekuje na przesłanie danych wyjściowych (w buforach wysyłania).

Aktualizacja 2011-08-05: Ustawienia, które zostały zmienione, aby osiągnąć cel ( /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

Specjalne ustawienia dla urządzenia bond (SLES: / etc / sysconfig / network / ifcfg-bond0 ):

MTU='9216'
LINK_OPTIONS='txqueuelen 10000'

Pamiętaj, że ustawienie największego możliwego MTU było kluczem do rozwiązania.

Strojenie buforów rx / tx zaangażowanych kart sieciowych:

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

Miałem podobny problem, próbując zwiększyć prędkość synchronizacji drbd przez dwa łącza gigabitowe jakiś czas temu. W końcu udało mi się uzyskać szybkość synchronizacji około 150 MB / s. Oto ustawienia, które zastosowałem na obu węzłach:

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

Możesz także spróbować włączyć przerywanie koalescencji, jeśli nie masz jeszcze kart sieciowych (z ethtool --coalesce )

Czy skonfigurowałeś ten dwukierunkowy bagażnik na przełączniku? jeśli nie, to nie będzie tak działać, po prostu będzie działać w trybie aktywnym / pasywnym i będzie używać tylko 1 łącza 1 Gb / s.

Wygląda na to, że PowerEdge 6950 jest ograniczony do potencjalnie gniazd PCI, które osiągają maksimum 133 MB / s w całej magistrali. Być może widzisz ograniczenia we / wy samej architektury magistrali systemowej.

Oprócz testowania innych systemów z innym sprzętem i architekturą I / O, może również pojawić się okablowanie. Niektóre możliwe kombinacje mogą mieć różne oceny (5e vs. 6), a także długości (krótsze nie zawsze jest lepsze).

Duże ramki?

ifconfig <interface> mtu 9000

robienie dużych ramek jest ogromną pomocą, o ile twój przełącznik i nic go obsługują. jeśli masz niezarządzane przechwytywanie, najprawdopodobniej nie dostaniesz się gdziekolwiek chcesz dla przepustowości, ale nie dzieje się tak, jeśli łączysz porty na przełączniku. oto coś, czego nauczyłem się dawno temu, w 65% przypadków, jest to problem fizyczny. używasz kabla cat6?

jeśli skonfigurowałeś duże ramki w swojej karcie sieciowej, które wyglądają tak, upewnij się, że skonfigurowałeś przełączniki tak, aby obsługiwały również wysokie MTU.

Ramki typu Jumbo mają doskonałą wydajność w sieciach gigabitowych, ale musisz upewnić się, że zostały skonfigurowane od końca do końca (zarówno serwery źródłowe, jak i docelowe oraz używane przełączniki sieciowe).