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

Alguém tem alguns dados ou cálculos básicos que podem responder quando é necessária a coalescência de quadros (NAPI) e quando uma única interrupção por quadro é suficiente?

Meu hardware: IBM BladeServer HS22, hardware Broadcom 5709 Gigabit NIC (MSI-X), com dois processadores quad-core Xeon E5530. O principal objetivo é o servidor proxy Squid. O switch é um bom Cisco 6500 series.

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. Fiz muitos ajustes e atualização do kernel para 2.6.38 e melhorou a perda de pacotes, mas a latência ainda é baixa. Pings são esporádicos; pulando até 200ms na LAN local de Gbps. A resposta média do Squid salta de 30ms para 500 + ms, mesmo que 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; Instalei o irqbalance para equilibrar os IRQs (8 cada um para eth0 e eth1) em todos os núcleos, mas isso não ajudou muito.

As NICs da Intel parecem nunca ter esse tipo de problema, mas, como o sistema de lâminas e o hardware de configuração fixa, estamos meio que presos às Broadcoms.

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

Infelizmente, o bnx2 não suporta adaptive-rx ou tx.

A resposta do encadeamento NAPI versus interrupções adaptativas fornece uma excelente visão geral da moderação de interrupção, mas não há informações concretas sobre como calcular as configurações ideais de coalescência do ettool para uma solução alternativa fornecida. Existe uma abordagem melhor do que apenas tentativa e erro?

A carga de trabalho acima mencionada e a configuração de hardware precisam de NAPI? Ou deveria poder viver com uma única interrupção por pacote?

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

Pelo menos posso responder à sua pergunta ", caso seja capaz de viver com uma única interrupção por pacote". Acho que a resposta é sim, com base em um firewall muito ocupado ao qual 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 equilíbrio manual de irq com / proc / irq / XXX / smp_affinity, por interface. Não sei por que eles escolheram seguir esse caminho em vez de irqbalance, mas parece funcionar.

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

Dito tudo isso, minha intuição é que você está de alguma forma ligado ao hardware aqui ... como em um firmware ou bug de interoperabilidade de algum tipo.

Certamente, considerando os recursos de CPU, chipset e barramento, em comparação com uma quantidade tão baixa de tráfego que você possui, não há motivo para NECESSITAR de qualquer forma de gerenciamento de interrupções. Temos várias máquinas RHEL 5.3 de 64 bits com placas de rede de 10 Gbps e suas interrupções não são tão ruins, isso é 100 vezes menor.

Obviamente, você tem uma configuração fixa (eu uso os blades da HP, que são bastante semelhantes), portanto, trocar NICs por Intels agora é uma opção fácil, mas o que eu diria é que estou começando a detectar vários problemas semelhantes neste fórum e em outros lugares com essa placa de rede Broadcom específica. Sempre os próprios sites SE tiveram alguns problemas com esse tipo de inconsistência e a troca por placas de rede Intel absolutamente ajudou.

O que eu recomendaria é escolher um único blade e adicionar um adaptador baseado em Intel a essa máquina. Obviamente, você precisará adicionar uma interconexão ou o que a IBM chamar para obter o sinal, mas tente a mesma configuração de software, mas com essa outra. NIC (provavelmente desative o Broadcom, se puder). Teste isso e veja como você se sai; sei que o que descrevi precisa de alguns bits extras de hardware, mas imagino que seu representante da IBM os emprestará com prazer. É a única maneira de saber com certeza. Informe-nos o que você descobriu. Estou realmente interessado se houver um problema com essas placas de rede, mesmo que seja um caso estranho. Além disso, vou me encontrar com a Intel e a Broadcom na próxima semana para discutir algo totalmente não relacionado, mas certamente discutirei isso com eles e avisarei se encontrar algo de interesse.

A questão das interrupções é como elas afetam o desempenho geral do sistema. As interrupções podem antecipar o processamento de terra do usuário e do kernel e, embora você não veja muito uso da CPU, há muita troca de contexto ocorrendo e isso é um grande impacto no desempenho. Você pode usar vmstate verificar a systemcoluna, o cscabeçalho para as interrupções e as alternâncias de contexto por segundo (as interrupções incluem o relógio para que você pesa isso), vale a pena conferir também.

A resposta curta e direta:

Se você ativar a pesquisa, você reduzirá as alternâncias de contexto (normalmente devido a interrupções) do que elas são agora (15 kips no seu caso) para um número predeterminado (geralmente 1k a 2k).

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

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 executou mais de 900 Mbps / 150 kpps. Isso ainda está usando os mesmos chipsets Broadcom bnx2.

Então, para concluir: o tratamento de interrupções 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 placas de rede Intel para que possamos usar pacotes Debian padrão. Combater o firmware bnx2 não livre tem sido uma enorme perda de tempo.