Como ajustar o desempenho do TCP no Linux com uma conexão de fibra de 10Gb

Question

Temos dois servidores da Red Hat dedicados ao teste de velocidade do cliente. Ambos usam conexões de fibra de 10 Gb e ficam em links de 10 Gb. Todos os equipamentos de rede entre esses servidores suportam totalmente 10Gb / s. Usando o Iperf ou o Iperf3, o melhor que posso obter é em torno de 6,67 Gb / s. Dito isto, um servidor está em produção (os clientes estão acertando) e o outro servidor está online, mas não está sendo usado. (estamos a usá-lo para testes atm) O 6.67Gb / s também é uma maneira, devo mencionar. Vamos chamar esses servidores A e B.

Quando o servidor A atua como o servidor iperf, obtemos as velocidades de 6,67 Gb / s. Quando o servidor A atua como o cliente para o servidor B, ele só pode enviar cerca de 20Mb / s.

O que eu fiz:

Até agora, a única coisa que fiz foi aumentar os buffers TX / RX em ambos os servidores para o máximo. Um foi definido para 512 o outro 453. (RX apenas, TX já estava no máximo), então aqui está o que parece em ambos após a atualização:

Server A:
Ring parameters for em1:
Pre-set maximums:
RX:     4096
RX Mini:    0
RX Jumbo:   0
TX:     4096
Current hardware settings:
RX:     4096
RX Mini:    0
RX Jumbo:   0
TX:     4096

Server B:
Ring parameters for p1p1:
Pre-set maximums:
RX:     4078
RX Mini:    0
RX Jumbo:   0
TX:     4078
Current hardware settings:
RX:     4078
RX Mini:    0
RX Jumbo:   0
TX:     4078

O NICS é assim:

Server A: 
ixgbe 0000:01:00.0: em1: NIC Link is Up 10 Gbps, Flow Control: RX/TX

Serer B:
bnx2x 0000:05:00.0: p1p1: NIC Link is Up, 10000 Mbps full duplex,     Flow control: ON - receive & transmit

Server A ethtool stats:
 rx_errors: 0
 tx_errors: 0
 rx_over_errors: 0
 rx_crc_errors: 0
 rx_frame_errors: 0
 rx_fifo_errors: 0
 rx_missed_errors: 0
 tx_aborted_errors: 0
 tx_carrier_errors: 0
 tx_fifo_errors: 0
 tx_heartbeat_errors: 0
 rx_long_length_errors: 0
 rx_short_length_errors: 0
 rx_csum_offload_errors: 123049

 Server B ethtool stats:
 [0]: rx_phy_ip_err_discards: 0
 [0]: rx_csum_offload_errors: 0
 [1]: rx_phy_ip_err_discards: 0
 [1]: rx_csum_offload_errors: 0
 [2]: rx_phy_ip_err_discards: 0
 [2]: rx_csum_offload_errors: 0
 [3]: rx_phy_ip_err_discards: 0
 [3]: rx_csum_offload_errors: 0
 [4]: rx_phy_ip_err_discards: 0
 [4]: rx_csum_offload_errors: 0
 [5]: rx_phy_ip_err_discards: 0
 [5]: rx_csum_offload_errors: 0
 [6]: rx_phy_ip_err_discards: 0
 [6]: rx_csum_offload_errors: 0
 [7]: rx_phy_ip_err_discards: 0
 [7]: rx_csum_offload_errors: 0
 rx_error_bytes: 0
 rx_crc_errors: 0
 rx_align_errors: 0
 rx_phy_ip_err_discards: 0
 rx_csum_offload_errors: 0
 tx_error_bytes: 0
 tx_mac_errors: 0
 tx_carrier_errors: 0
 tx_deferred: 0
 recoverable_errors: 0
 unrecoverable_errors: 0

Problema potencial: o servidor A tem toneladas de rx_csum_offload_errors. O servidor A é o que está em produção e não posso deixar de pensar que as interrupções da CPU podem ser um fator subjacente aqui e o que está causando os erros que vejo.

cat / proc / interrupts do servidor A:

122:   54938283          0          0          0          0            0          0          0          0          0          0          0            0          0          0          0          0          0          0           0          0          0          0          0  IR-PCI-MSI-edge      em1-  TxRx-0
123:   51653771          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-1
124:   52277181          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-2
125:   51823314          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-3
126:   57975011          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-4
127:   52333500          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-5
128:   51899210          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-6
129:   61106425          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-7
130:   51774758          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-8
131:   52476407          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-9
132:   53331215          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-edge      em1-TxRx-10
133:   52135886          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0

Desabilitar a ajuda do rx-checksumming se esse é o problema? Também não vejo interrupções da CPU no servidor que não está em produção, o que faz sentido, já que sua NIC não está precisando de tempo de CPU.

Server A:
 ethtool -k em1
Features for em1:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-unneeded: off
tx-checksum-ip-generic: off
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: on [fixed]
tx-checksum-sctp: on [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: on [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
loopback: off [fixed]

Além de usar quadros jumbo, o que não é possível porque o nosso equipamento de rede não os suporta, o que mais eu posso fazer ou verificar para fornecer o melhor desempenho TCP para a minha rede de 10 Gb? O 6.67Gb / s não é esse ruim, eu acho que levando em consideração que um dos servidores está em produção e minha hipótese sobre as interrupções de CPU que o NIC está gerando. Mas a velocidade de 20Mb / s na outra direção em um link de 10Gb simplesmente não é aceitável. Qualquer ajuda seria muito apreciada.

Especificações do servidor A: CPU x64 24v 32 GB de RAM RHEL 6.7

Especificações do servidor B: CPU x64 16v Ram 16GB RHEL 6.7

    

Answer 1

No Linux / Intel, usaria a seguinte metodologia para análise de desempenho:

Hardware:

• turbostat
  Procure por estados C / P para núcleos, frequências, número de SMIs. [1]
• cpufreq-info
  Procure por driver atual, freqüências e governador.
• atop
  Procure por distribuição de interrupções nos núcleos | Procure interruptores de contexto, interrupções.
• ethtool
  -S para estatísticas, procure erros, quedas, excesso de interrupções, interrupções perdidas, etc.
  -k para offloads, habilite GRO / GSO, rss (/ rps / rfs) / xps
  -g para tamanhos de anel, aumentar
  -c para interromper a coalescência

Kernel:

• /proc/net/softirq [2] e /proc/interrupts [3]
  Mais uma vez, distribuição, falta, interrupções atrasadas, (opcional) NUMA-afinidade
• perf top
  Veja onde o kernel / benchmark gasta seu tempo.
• iptables
  Veja se há regras (se houver) que possam afetar o desempenho.
• netstat -s , netstat -m , /proc/net/*
  Procure contadores de erros e contagens de buffer
• sysctl / grub
  Tanto para ajustar aqui. Tente aumentar os tamanhos de hash, jogando com buffers de memória, controle de congestionamento e outros botões.

No seu caso, seu principal problema é interromper a distribuição entre os núcleos, então consertá-lo será o melhor caminho de ação.

PS. Não se esqueça que nesses tipos de benchmarks as versões do kernel e driver / firmware desempenham um papel significativo.

PPS. Você provavelmente deseja instalar o driver ixgbe mais recente da Intel [4]. Não esqueça de ler o README lá e examinar o diretório de scripts. Tem muitas dicas relacionadas ao desempenho.

[0] A Intel também possui documentos interessantes sobre como dimensionar o desempenho da rede link < br> [1] Você pode fixar seu processador em um estado C específico: link
[2] Você pode analisar esses dados com: link
[3] Você pode definir afinidade com: link
[4] link

    

Answer 2

São os servidores das mesmas especificações (marca e modelo)? Você fez alguma alteração em sysctl.conf?

Você deve habilitar o irqbalance porque suas interrupções estão ocorrendo apenas no CPU0.

Se você não estiver usando um perfil ajustado com o EL6, escolha um que seja próximo à sua carga de trabalho, de acordo com a programação aqui .

    

Answer 3

Velocidade 6 Gb / s é ok, se você executar apenas uma instância do iperf, já que ela é limitada ao núcleo da CPU. Dois processos simultaneamente devem fornecer 10Gb / s esperados.

O problema com 20Mb / s em uma direção parece um problema de incompatibilidade de driver / firmware / hardware.

Sugiro que você tente as seguintes etapas de solução de problemas:

Suas NICs têm portas duplas, então, primeiro, tente testes de velocidade de loopback em ambas as NICs. Pode ajudá-lo a localizar o problema: no servidor A ou no servidor B.  2. Altere os cabos de manobra.  3. Tente novos drivers.  4. Atualize o firmware.  5. Alterar NICs)

    

Answer 4

Eu tentaria desabilitar o LRO (Large Receive Offload) ... Eu acho que você tem um com ele ligado, e um com ele desligado.

É dependente de NIC / driver, mas em geral, quando vemos que em nosso ambiente, sabemos que perdemos um e desativamos LRO