Quais cargas de rede requerem pesquisa de NIC versus interrupções?

Question

Alguém tem alguns dados ou cálculos básicos que podem responder quando o NAPI (frame coalescing) é necessário e quando uma única interrupção por quadro é suficiente?

Meu hardware: IBM BladeServer HS22, hardware NIC Broadcom 5709 Gigabit (MSI-X), com dois processadores quad-core Xeon E5530. O objetivo principal é o servidor proxy do Squid. Switch é uma boa série Cisco 6500.

Nosso problema básico é que, durante os horários de pico (tráfego de 100 Mbps, apenas 10.000 pps), a latência e a perda de pacotes aumentam. Eu fiz um monte de tuning e atualização do kernel para o 2.6.38 e melhorou a perda de pacotes, mas a latência ainda é ruim. Os pings são esporádicos; saltando até 200ms na LAN de Gbps local. A resposta média do Squid aumenta de 30ms para 500 + ms, embora a carga da CPU / memória esteja boa.

As interrupções aumentam para cerca de 15.000 / segundo durante o pico. O Ksoftirqd não está usando muita CPU; Eu instalei o irqbalance para balancear os IRQs (8 para eth0 e eth1) em todos os núcleos, mas isso não ajudou muito.

Intel NICs parecem nunca ter esse tipo de problema, mas com o fato do hardware e hardware de configuração fixa, nós estamos presos aos Broadcoms.

Tudo está apontando para o NIC como o principal culpado. A melhor idéia que tenho agora é tentar diminuir as interrupções, mantendo a latência baixa e a taxa de transferência alta.

O bnx2 infelizmente não suporta adaptive-rx ou tx.

A resposta de thread NAPI vs Adaptive Interrupts oferece uma excelente visão geral da moderação de interrupções, mas não informações concretas sobre como calcular as configurações ideais de coalescência de ethtool para determinada solução alternativa. Existe uma abordagem melhor do que tentativa e erro?

A configuração da carga de trabalho e do hardware mencionada acima precisa mesmo do NAPI? Ou deveria ser capaz de viver em uma única interrupção por pacote?

    

Answer 1

Grande pergunta que me fez ler para tentar descobrir. Gostaria de poder dizer que tenho uma resposta ... mas talvez algumas dicas.

Eu posso pelo menos responder a sua pergunta, "deveria ser capaz de viver em uma única interrupção por pacote". Eu acho que a resposta é sim, com base em um firewall muito ocupado que eu tenho acesso:

Saída Sar:

03:04:53 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
03:04:54 PM        lo     93.00     93.00      6.12      6.12      0.00      0.00      0.00
03:04:54 PM      eth0 115263.00 134750.00  13280.63  41633.46      0.00      0.00      5.00
03:04:54 PM      eth8  70329.00  55480.00  20132.62   6314.51      0.00      0.00      0.00
03:04:54 PM      eth9  53907.00  66669.00   5820.42  21123.55      0.00      0.00      0.00
03:04:54 PM     eth10      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM     eth11      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth2 146520.00 111904.00  45228.32  12251.48      0.00      0.00     10.00
03:04:54 PM      eth3    252.00  23446.00     21.34   4667.20      0.00      0.00      0.00
03:04:54 PM      eth4      8.00     10.00      0.68      0.76      0.00      0.00      0.00
03:04:54 PM      eth5      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth6   3929.00   2088.00   1368.01    183.79      0.00      0.00      1.00
03:04:54 PM      eth7     13.00     17.00      1.42      1.19      0.00      0.00      0.00
03:04:54 PM     bond0 169170.00 201419.00  19101.04  62757.00      0.00      0.00      5.00
03:04:54 PM     bond1 216849.00 167384.00  65360.94  18565.99      0.00      0.00     10.00

Como você pode ver, alguns pacotes muito altos por segundo contam, e nenhum ajuste especial de ethtool foi feito nesta máquina. Oh ... chipset Intel, no entanto. : \

A única coisa que foi feita foi um balanceamento irq manual com / proc / irq / XXX / smp_affinity, em uma base por interface. Eu não tenho certeza por que eles escolheram ir desse jeito em vez de com o irqbalance, mas parece funcionar.

Também pensei na matemática necessária para responder à sua pergunta, mas acho que há muitas variáveis. Então ... para resumir, na minha opinião, a resposta é não, eu não acho que você pode prever os resultados aqui, mas com captura de dados suficiente você deve ser capaz de ajustá-lo para um nível melhor.

Tendo dito tudo isso, meu instinto é que você está de alguma forma ligado ao hardware aqui ... como em um bug de firmware ou de interoperabilidade de algum tipo.

    

Answer 2

Certamente, considerando as capacidades de CPU, chipset e barramento em comparação a uma quantidade tão baixa de tráfego que você tem, não há motivo algum para você PRECISAR de qualquer forma de gerenciamento de interrupções. Temos várias máquinas RHEL 5.3 de 64 bits com NICs de 10 Gbps e suas interrupções não são muito ruins, isso é 100 vezes menor.

Obviamente você tem uma configuração fixa (eu uso os blades da HP que são bem parecidos) então trocar as placas de rede pelo Intels agora é uma opção fácil, mas o que eu diria é que eu estou começando a identificar uma série de problemas semelhantes em torno deste fórum e em outro lugar com esse NIC Broadcom particular. Sempre os próprios sites da SE tiveram alguns problemas com esse tipo de inconsistência e a troca para NICs da Intel foi absolutamente útil.

O que eu recomendo é escolher um único blade e adicionar um adaptador baseado em Intel a essa máquina, obviamente você terá que adicionar uma interconexão ou qualquer outra chamada IBM para obtê-lo, mas tente a mesma configuração de software, mas com este outro NIC (provavelmente desative o Broadcom se puder). Teste isso e veja como você se sai, sei que o que eu descrevi precisa de alguns bits de hardware extra, mas imagino que seu representante IBM irá emprestá-los com prazer. É a única maneira de saber com certeza. Por favor, deixe-nos saber o que você descobriu, estou genuinamente interessado se houver um problema com esses NICs, mesmo que seja um caso estranho. Como um aparte, vou me reunir com a Intel e a Broadcom na próxima semana para discutir algo totalmente não relacionado, mas certamente irei discuti-lo com eles e avisá-lo se encontrar algo de interesse.

    

Answer 3

A questão sobre interrupções é como elas afetam o desempenho geral do sistema. As interrupções podem antecipar o processamento do usuário e do kernel e, embora você não consiga ver muito uso da CPU, ocorre muita comutação de contexto e isso é um grande impacto no desempenho. Você pode usar vmstat e verificar a coluna system , cs para as interrupções e as mudanças de contexto por segundo (as interrupções incluem o relógio, então você deve ponderar isso), vale a pena verificar também.

    

Answer 4

A resposta direta curta:

Se você habilitar o polling, você reduzirá as mudanças de contexto (normalmente devido a interupts) de qualquer que seja agora (15kips no seu caso) para um número predeterminado (geralmente de 1k para 2k).

Se você atualmente tem tráfego acima do número predeterminado, deverá ter melhores tempos de resposta ativando a pesquisa. O contrário também é verdade. Eu não diria que isso é "necessário", a menos que as alternâncias de contexto estejam afetando o desempenho.

    

Answer 5

Para acompanhar: com os módulos NAT e Conntrack descarregados e o conjunto de regras minimizado do iptables, obtemos um ótimo desempenho. O balanceador de carga IPVS fez mais de 900 Mbps / 150 kpps. Isso é enquanto ainda usa os mesmos chipsets Broadcom bnx2.

Então, para concluir: o manuseio da interrupção parece bom e os padrões para o Debian com o kernel 2.6.38 / 3.0.x parecem ter um desempenho aceitável.

Definitivamente, eu preferiria usar NICs da Intel para que possamos usar pacotes Debian padrão. Lutar contra o firmware bnx2 não-livre tem sido uma enorme perda de tempo.