Perché il mio gigabit bond non eroga almeno 150 MB / s di throughput?

Ho collegato direttamente due crossover PowerEdge 6950 (usando linee rette) su due diversi adattatori PCIe.

Ottengo un collegamento gigabit su ciascuna di queste linee (1000 MBit, full duplex, controllo del flusso in entrambe le direzioni).

Ora sto cercando di collegare queste interfacce in bond0 usando l'algoritmo rr su entrambi i lati (voglio ottenere 2000 MBit per una singola sessione IP).

Quando ho testato il throughput trasferendo / dev / zero su / dev / null usando dd bs = 1M e netcat in modalità tcp ottengo un throughput di 70 MB / s - non - come previsto più di 150 MB / s.

Quando uso le singole linee ottengo circa 98 MB / s su ciascuna linea, se ho usato una direzione diversa per ogni linea. Quando uso le singole linee ottengo 70 MB / se 90 MB / s sulla linea, se il traffico va nella "stessa" direzione.

Dopo aver letto il readme di bonding (/usr/src/linux/Documentation/networking/bonding.txt) ho trovato utile la seguente sezione: (13.1.1 Selezione della modalità Bonding MT per topologia a singolo switch)

balance-rr: questa modalità è l'unica modalità che consentirà a una singola connessione TCP / IP di trasferire il traffico su più interfacce. È quindi l'unica modalità che consentirà a un singolo flusso TCP / IP di utilizzare più di una velocità di trasmissione di un'interfaccia. Questo ha un costo, tuttavia: lo striping comporta spesso che i sistemi peer ricevano i pacchetti fuori servizio, causando l'avvio del sistema di controllo della congestione di TCP / IP, spesso ritrasmettendo segmenti.

    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.

Ora ho modificato quel parametro su entrambi i server collegati su tutte le linee (4) da 3 a 127.

Dopo aver nuovamente incollato ottengo circa 100 MB / s, ma non di più.

Qualche idea sul perché?

Aggiornamento: dettagli hardware da 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

Aggiorna i risultati finali:

8589934592 byte (8,6 GB) copiati, 35,8489 secondi, 240 MB / s

Ho cambiato molte opzioni di tcp / ip e driver di basso livello. Ciò include l'ampliamento dei buffer di rete. Questo è il motivo per cui ddora mostra numeri maggiori di 200 MB / s: dd termina mentre c'è ancora un output in attesa di essere trasferito (nei buffer di invio).

Aggiornamento 2011-08-05: Impostazioni modificate per raggiungere l'obiettivo ( /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

Impostazioni speciali per il dispositivo bond (SLES: / etc / sysconfig / network / ifcfg-bond0 ):

MTU='9216'
LINK_OPTIONS='txqueuelen 10000'

Si noti che l'impostazione della MTU più grande possibile è stata la chiave della soluzione.

Ottimizzazione dei buffer rx / tx delle schede di rete interessate:

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

Ho avuto un problema simile nel tentativo di aumentare la velocità di una sincronizzazione DRDB su due collegamenti Gigabit qualche tempo fa. Alla fine sono riuscito a ottenere una velocità di sincronizzazione di circa 150 MB / sec. Queste erano le impostazioni che ho applicato su entrambi i nodi:

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

Potresti anche provare ad abilitare la coalescenza di interruzione se non lo hai già per le tue schede di rete (con ethtool --coalesce )

Hai configurato questo trunk a due vie sullo switch? in caso contrario, non funzionerà in questo modo, funzionerà solo in modalità attiva / passiva e utilizzerà solo 1 dei collegamenti 1Gbps.

Sembra che PowerEdge 6950 sia limitato a possibili slot PCI che superano i 133 MB / s condivisi su tutto il bus. Potresti riscontrare limitazioni I / O sull'architettura del bus di sistema stesso.

Oltre ad avere altri sistemi con hardware e architetture I / O diversi da testare, anche i cavi potrebbero entrare in gioco. Alcune possibili combinazioni possono essere lungo le linee di diverse valutazioni (5e contro 6) e lunghezze (più corto non è sempre migliore).

Frame Jumbo?

ifconfig <interface> mtu 9000

fare jumbo frame è un aiuto gigantesco, purché il tuo switch e nic lo supportino. se si dispone di un siwtch non gestito, molto probabilmente non si arriva dove si desidera per la larghezza di banda, ma non è così se si collegano le porte sullo switch. ecco qualcosa che ho imparato molto tempo fa, il 65% delle volte, è un problema fisico. stai usando il cavo cat6?

se hai configurato jumbo frame sulle tue schede di rete che dall'aspetto hai assicurato di aver configurato i tuoi switch per supportare anche l'MTU alto.

I frame jumbo offrono prestazioni eccezionali su reti gigabit, ma è necessario assicurarsi di averli configurati end-to-end (sia i server di origine che di destinazione e gli switch di rete che utilizzano).