Por que meu vínculo de gigabit não fornece uma taxa de transferência de pelo menos 150 MB / s?


17

Conectei diretamente dois crossovers 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, controle de fluxo nas duas direções).

Agora, estou tentando vincular essas interfaces ao bond0 usando o algoritmo rr dos dois lados (quero obter 2000 MBit para uma única sessão IP).

Quando testei a taxa de transferência transferindo / dev / zero para / dev / null usando dd bs = 1M e netcat no modo tcp, recebo uma taxa de transferência de 70 MB / s - não - conforme o esperado, mais de 150 MB / s.

Quando uso as linhas únicas, obtenho cerca de 98 MB / s em cada linha, se eu tiver usado uma direção diferente para cada linha. Quando uso as linhas únicas, obtenho 70 MB / se 90 MB / s na linha, se o tráfego for na mesma direção.

Depois de ler o bonding-readme (/usr/src/linux/Documentation/networking/bonding.txt), achei a seguinte seção útil: (13.1.1 Seleção do modo de ligação MT para topologia de comutador único)

balance-rr: esse modo é o único modo que permitirá que uma única conexão TCP / IP distribua o tráfego por várias interfaces. Portanto, é o único modo que permitirá que um único fluxo TCP / IP utilize mais do que uma interface de taxa de transferência. Porém, isso tem um custo: a distribuição geralmente resulta em sistemas pares recebendo pacotes fora de ordem, fazendo com que o sistema de controle de congestionamento do TCP / IP seja ativado, geralmente retransmitindo segmentos.

    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 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 idéia do porquê?

Atualização: detalhes de 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) copiados, 35,8489 segundos, 240 MB / s

Alterei muitas opções de tcp / ip e driver de baixo nível. Isso inclui a ampliação dos buffers de rede. É por isso que ddagora mostra números maiores que 200 MB / s: o dd termina enquanto ainda há saída aguardando transferência (nos buffers de envio).

Atualização 2011-08-05: Configurações que foram alteradas para atingir a meta ( /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 bond (SLES: / etc / sysconfig / network / ifcfg-bond0 ):

MTU='9216'
LINK_OPTIONS='txqueuelen 10000'

Observe que definir a maior MTU possível foi a chave da 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

Você verificou /proc/net/bonding/bond0se está realmente sendo definido para balance-rr ? Você viu a observação de que a documentação que você colou sobre um vínculo de 4 interfaces oferece apenas 2,3 interfaces de rendimento? Dada essa nota, parece altamente improvável que você chegue perto dos 2000mb / s que deseja.
Zoredache

Não tenho certeza de que o LACP / Bonding possa dividir uma única sessão TCP em vários links físicos.
Kedare

@Kedare, esse não é o LACP, é o próprio agendador de pacotes round-robin do Linux, que pode utilizar vários links para uma única sessão TCP.
Larsks

1
Uma maneira melhor de testar a taxa de transferência em um link é usar nuttcp. Teste conexões simples ou múltiplas com facilidade.
MikeyB

Respostas:


8

Eu tive um problema semelhante ao tentar aumentar a velocidade de uma sincronização drbd em dois links de gigabit há algum tempo. No final, consegui obter uma velocidade de sincronização de cerca de 150 MB / s. Estas foram as configurações que apliquei nos dois nós:

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

Você também pode tentar ativar a coalescência de interrupções se ainda não tiver suas placas de rede (com ethtool --coalesce )


Eu não sei. Não era necessário no meu caso. Definir esses parâmetros foi suficiente. Mas acho que se você definir, não vai doer. A taxa de transferência melhorou?
user842313

1
Atualmente, não posso testar isso, mas o mais provável é que seja. Sua dica sobre "coalescência" provavelmente atinge a marca. Encontrei um artigo interessante (em alemão) sobre as configurações de "Ethernet de alta velocidade". Os quadros jumbo seguem a mesma direção - trata-se de reduzir o número de interrupções pci necessárias para transferir a carga de trabalho.
Nils

Se você está pensando em algum gargalo hw como o limite de interrupções, uma ferramenta como o collectd definitivamente ajudará, embora isso exija um pouco de configuração. Veja, por exemplo, este gráfico
user842313 15/07/11

0

Você configurou esse tronco bidirecional no comutador? caso contrário, não funcionará dessa maneira, funcionará apenas no modo ativo / passivo e usará apenas um dos links de 1Gbps.


Não há dispositivo de rede envolvido. Estes são cabos cruzados diretos.
Nils

5
Ah, então você está sem sorte por outro motivo completamente diferente; Os troncos LACP / Etherchannel como esse dependem da variação no primeiro (e, se for o caso, no segundo e no terceiro) bit menos significativo do MAC de destino para definir qual membro do tronco é usado para se comunicar com esse MAC. Dado que você terá apenas um MAC para o tronco em cada extremidade, eles nunca usarão mais de um link.
Chopper3

2
ele não está usando o etherchannel / 802.3ad, ele está usando o balance-rr, que, para ser exato, nem sequer requer nenhum suporte de switch.
the-wabbit

@ Chopper3: Então a questão do MAC não deve aparecer no RR na sua opinião?
Nils

2
Não sei o suficiente para comentar, meio que desejei ter mencionado essas coisas antes, mas não importa.
Chopper3

0

Parece que o PowerEdge 6950 está limitado a possivelmente slots PCI, com 133 MB / s compartilhados em todo o barramento. Você pode estar vendo limitações de E / S na própria arquitetura do barramento do sistema.

Além de ter outros sistemas com diferentes arquiteturas de hardware e E / S para testar, o cabeamento também pode entrar em jogo. Algumas combinações possíveis podem estar na mesma linha de classificações diferentes (5e vs. 6) e também em comprimentos (menores nem sempre são melhores).


Eu já tenho 160 MB / s - usando as linhas únicas simultâneas. Mas isso cai para 100 MB / s após a ligação. Em cada linha, recebo quase 100 MB / s, de modo que os cabos também não parecem ser o problema.
Nils

Parece não haver nenhum suporte PCIe para o PowerEdge 6950. Algo "diferente" com seu barramento PCI? Não obstante, você pode consultar as especificações do barramento de
entrada

Eu atualizei a pergunta com a saída de lspci. Este não era o gargalo. Eu recebo meus 200 MB / s agora.
Nils

0

Jumbo frames?

ifconfig <interface> mtu 9000

Isso deve reduzir a carga da CPU, certo? Gostaria de saber o que a CPU está fazendo durante esses testes.
SpacemanSpiff

1
com uma MTU de 9000 em vez de 1500, você reduz o número de pacotes de dados tcp necessários para transferir a mesma quantidade de dados (a carga útil é maior). Portanto, você realiza menos processamento de pacotes, nos dois lados e nos dois sentidos, e envia mais dados.
Julien Vehent

Parece que vale a pena tentar. As CPUs estão bastante ociosas durante a transferência. Mas ainda tenho a sensação de que um link físico está aguardando um ACK antes que o kernel envie o próximo pacote no outro link físico.
Nils

Também estou curioso sobre o resultado. Além disso, tente vincular cada NIC a um núcleo da CPU. Um kernel recente deve lidar com isso adequadamente, mas não tenho certeza de como funcionaria com a ligação. A idéia é evitar alternar de um cache l2 para outro para cada pacote.
Julien Vehent

A carga da CPU não é um problema. Todas as opções de descarregamento estão ativadas ...
Nils

0

fazer jumbo frames é uma ajuda gigantesca, desde que o switch e o nic suportem. se você tiver um siwtch não gerenciado, provavelmente você não chegará aonde deseja a largura de banda, mas não é esse o caso se você estiver vinculando as portas no switch. aqui está algo que aprendi há muito tempo, 65% das vezes, é um problema físico. você está usando cabo cat6?


0

se você configurou jumbo-frames em suas placas de rede, pelo que você tem certeza de ter configurado seus switches para suportar também a alta MTU.

Os jumbo-frames são um ótimo desempenho em redes gigabit, mas é necessário garantir que você os tenha configurado de ponta a ponta (servidores de origem e de destino e os comutadores de rede que eles usam).


Não há dispositivos de rede envolvidos neste caso especial. (linhas de cruzamento diretas). Este também é o único caso (real) em que você pode usar o algoritmo RR para compartilhar a carga em todas as linhas em uma única sessão.
Nils
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.