interrompe a coalescência para captura de pacotes de alta largura de banda?

Question

Eu tenho um aplicativo que faz captura de pacotes de uma placa ethernet. De vez em quando, vemos os pacotes serem descartados (suspeitamos que o buffer na placa de rede ou o kernel esteja sobrecarregado). Eu estou tentando descobrir se ligar a coalescência interromper ajudará ou piorará a situação. Por um lado, deve haver menos trabalho na CPU, pois deve haver menos interrupções no processo; por outro lado, parece que se os IRQs não forem processados com tanta freqüência, há uma probabilidade maior de um buffer ser saturado. Isso significa que talvez eu deva ligá-lo e aumentar o tamanho das configurações de rmem_max?

ATUALIZADO PARA INCLUIR OS / HW Detalhes:

Dell PowerEdge 1950, Dual Quad-Core Xeon X5460 a 3.16GHz Broadcom NetXtreme II BCM5708 SO Linux

proc/sys/net/core
  dev_weight          64
  netdev_budget       300
  rmem_default        110592
  somaxconn           128
  wmem_max            16777216
  xfrm_aevent_rseqth  2
  message_burst       10
  netdev_max_backlog  65536
  rmem_max            16777216
  warnings            1
  xfrm_acq_expires    30
  xfrm_larval_drop    1
  message_cost        5
  optmem_max          20480
  rps_sock_overflow_entries 0
  wmem_default        110592
  xfrm_aevent_etime   10

    

Answer 1

Sem saber por que você está descartando pacotes, é impossível saber se isso ajudará ou não. Sua análise é fundamentalmente correta - se as interrupções chegam (são atendidas) com menos frequência, há uma chance maior de preenchimento de buffers, sendo todas as coisas iguais. Se você não sabe por que está perdendo pacotes, no entanto, não pode saber se essa mudança melhorará ou não a situação.

Pessoalmente, acho que jogar NICs de boa qualidade com bons drivers em um servidor de boa qualidade faz com que todos os meus problemas desapareçam. Muito mais barato que passar dias rastejando pelos dados de depuração.

    

Answer 2

Ok, você não forneceu algumas das informações básicas (como uma distribuição específica do sistema operacional ou uma versão do kernel). Isso é importante porque os padrões de configuração sysctl / kernel diferem entre distros e certos tunables não são expostos em alguns sistemas Linux. Você está trabalhando com um servidor a partir de 2008, então como sabemos que seu sistema operacional e kernel não são da mesma época?

Analisando seus parâmetros de rede, porém, eu aumentaria os tamanhos de buffer padrão. Uma configuração recente do sistema para negociação de alta frequência que eu implantei tinha configurações wmem_default e rmem_default muito mais altas. Experimente "8388608" para começar e veja se isso ajuda. É uma mudança básica, mas geralmente o primeiro passo ...

Também gostaria de analisar as prioridades em tempo real de seu aplicativo (presumivelmente personalizado). Você está usando alguma forma de afinidade de CPU ( taskset , cgroups) no seu aplicativo ou script de wrapper? Como sobre a prioridade em tempo real do seu aplicativo? Examine o comando chrt e suas opções para ver o que seria apropriado para sua situação. Sua aplicação é multithreaded?

Felizmente, a CPU da série 5400 não tem hyperthreading para lidar, mas como estão suas outras configurações da BIOS? Você desabilitou o gerenciamento de energia e os estados C? Existem daemons desnecessários em execução no sistema? O irqbalance está em execução?

Agora, quanto ao hardware que você está usando, se isso for para o uso de HFT, você estará atrasado; literalmente TRÊS saltos na CPU e mudanças arquitetônicas ... O Nehalem (série 5500) trouxe um grande salto em tecnologia sobre a série 5400 que você está usando. Westmere (5600) foi ainda melhor. Sandy Bridge foi uma mudança grande o suficiente sobre o 5500/5600 para estimular outra atualização de hardware em meus ambientes.

Também parece que você está usando as NICs onboard. Havia alguns aros que precisávamos para passar ao lidar com Broadcom ... Mas você não está nesse ponto ainda. Como a carga da CPU parece quando você encontra pacotes descartados? Que tipo de fluxo de dados você está enfrentando durante suas capturas? Isso pode ser apenas um caso de seu sistema não acompanhar.

Existem muitos botões para ajustar / ajustar aqui. Uma melhor compreensão do que você está trabalhando nos ajudará a restringir as coisas, no entanto.

Edit: você mencionou a Red Hat. As opções para EL5 e EL6 diferem, mas as sugestões acima se aplicam em teoria.

Edit: É bom que você esteja no RHEL 6. Há muita coisa que você pode fazer. Tente definir a prioridade do seu aplicativo e teste. Outro guia útil é o Guia de ajuste do RHEL MRG . Nem todos os recursos estarão disponíveis para o seu kernel, mas isso lhe dará algumas idéias e explicações para algumas das coisas que você pode modificar para um desempenho mais determinista.