Eu conectei diretamente dois crossover PowerEdge 6950 (usando linhas retas) em dois adaptadores PCIe diferentes.
Eu recebo um link de gigabit em cada uma dessas linhas (1000 MBit, full duplex, fluxo contol em ambas as direções).
Agora estou tentando vincular essas interfaces ao bond0 usando o algoritmo rr em ambos os lados (eu quero obter 2000 MBit para uma única sessão IP).
Quando eu testei o throughput transferindo / dev / zero para / dev / null usando dd bs = 1M e netcat no modo tcp, obtive uma taxa de transferência de 70 MB / s - não - como esperado mais de 150MB / s. / p>
Quando eu uso as linhas simples, recebo cerca de 98 MB / s em cada linha, se eu usei uma direção diferente para cada linha.
Quando eu uso as linhas únicas eu ganho 70 MB / se 90 MB / s na linha, se o tráfego entrar na direção "mesma".
Depois de ler o readme de ligação (/usr/src/linux/Documentation/networking/bonding.txt), achei a seção a seguir como sendo útil: (13.1.1 Seleção do Modo de Ligação MT para Topologia de Comutador Único)
balance-rr:
This mode is the only mode that will permit a single
TCP/IP connection to stripe traffic across multiple
interfaces. It is therefore the only mode that will allow a
single TCP/IP stream to utilize more than one interface's
worth of throughput. This comes at a cost, however: the
striping often results in peer systems receiving packets out
of order, causing TCP/IP's congestion control system to kick
in, often by retransmitting segments.
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.
Agora eu mudei esse parâmetro nos dois servidores conectados em todas as linhas (4) de 3 para 127.
Após a ligação novamente, recebo cerca de 100 MB / s, mas ainda não mais do que isso.
Alguma ideia do porquê?
Atualização: detalhes do hardware de 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
Atualize os resultados finais:
8589934592 bytes (8.6 GB) copied, 35.8489 seconds, 240 MB/s
Mudei muitas opções de tcp / ip e driver de baixo nível. Isso inclui o aumento dos buffers de rede. É por isso que dd agora mostra números maiores que 200 MB / s: dd termina enquanto ainda há saída esperando para ser transferida (em buffers de envio).
Atualização 2011-08-05: Configurações que foram alteradas para atingir o objetivo ( /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
Configurações especiais para o dispositivo de ligação (SLES: / etc / sysconfig / network / ifcfg-bond0 ):
MTU='9216'
LINK_OPTIONS='txqueuelen 10000'
Observe que a configuração da maior MTU possível foi a chave para a solução.
Ajuste dos buffers rx / tx das placas de rede envolvidas:
/usr/sbin/ethtool -G eth2 rx 2048 tx 2048
/usr/sbin/ethtool -G eth4 rx 2048 tx 2048