[GTER] Uso intensivo de ksoftirq no Server U L-800+Red Hat+Quagga+VRRP Keepalived.

[Antonio Modesto]

On 2015-06-02 11:07 am, Noilson Caio wrote: 

> Kalil, seria uma boa
iniciar a procura por uso de IRQS e identificar o
> causador no pseudo
kernel. cat /proc/interrupts. As vezes ocorre o fato de
> terem irqs
compartilhadas, coisa que pode não ocorrer no segundo server.
> Verifica
se o irqbalance tá ativo nela. Use o ethtool para verificar se tem
>
problemas de buffer, drops nas interfaces, faz este mini
troubleshooting.
> 
> att
> 
> 2015-06-02 8:19 GMT-03:00 Kalil de A.
Carvalho <kalilac at gmail.com>:
> 
>> Bom dia pessoal. Não sei se alguem
já passou por isso mas estamos com um problema bastante estranho: Na
empresa que trabalho temos um ServerU L-800 com 16GB de RAM rodando Red
Hat 7.0, Quagga 0.99.22.4 (pacote da própria distribuição) e Keepalived
servindo como nosso roteador de borda. Fechamos sessões BGP com três
operadoras e recebemos rota full de todas elas. A mais ou menos três
semanas identificamos que o serviço ksoftirq ficava com uso de 100% em
um dos núcleos do nosso servidor e apesar de termos outros sete o
desempenho era bastante afetado, nosso clientes reclamavam, nosso
sistema de monitoramento mostrava uma queda de 60% no nosso consumo
durante o problema. Como temos uma outra maquina exatamente igual, a
outra ponta do VRRP, viramos o roteamento e reiniciamos a maquina. Com a
normalização voltamos o serviço para a primeira e tudo ficou normal por
aproximadamente cinco dias. Depois deste tempo o problema retornou.
Desta vez ao foi tentado uma abordagem diferente: Paramos o Keepalived,
forçando o roteamento a mudar, mas não reiniciamos o servidor. Depois de
uns quarenta minutos o ksoftirq normalizou. E é este o caso que temos
agora. O que quero chamar a atenção é que o nosso roteador secundário. o
que esta rodando neste momento, esta com as mesmas configurações e não
esta apresentando qualquer pico ou gargalo. Reafirmo que o problema
ocorreu a umas três semanas atrás, sem nenhuma atualização. Buscando na
Internet por problemas com VRRP achei apenas postagens antigas falando
de problemas quanto a recebimento de arp ou bug na versão. Na nossa
configuração não utilizamos multicast para consultas do Keepalived e sim
unicast. Mesmo assim, se fosse bug ou arp storm acredito que o
secundário também teria problema o que não é o caso. Abri chamado junto
a Red Hat e me pediram para pegar os dados via comando perf durante o
problema, o que foi feito. Eles alegam que o problema ocorre no momento
de alguma mudança de vizinhança, já que tem um intensivo uso de
processamento que pode estar causando isso tendo como suporte a esta
teoria uma mudança em um dos nossos pares BGP. Respondi que é uma ação
comum realizarmos reset nas vizinhanças e nunca tivemos nenhum problema,
o que reforça esta minha certeza é que o servidor secundário tem as
mesmas conexões que o primário, somente mudando os IP's mas sofrendo
qualquer modificação que o primário passar já que as operadoras fornecem
o mesmo caminho apenas com IP's secundarios nas conexões. Alguém já
passou por uma situação como esta? -- Atenciosamente, Kalil de A.
Carvalho -- gter list https://eng.registro.br/mailman/listinfo/gter
[1]
> 
>> Sei que não é a solução fácil para o seu problema, mas o
FreeBSD se comportou muito melhor nos testes que fiz no L-100 comparado
com o Linux. Enquanto no FreeBSD consegui 800Mb/s full-duplex com
pacotes de tamanho aleatório, no Linux o máximo que consegui foi
400Mb/s. Creio que com o L-800 o FreeBSD conseguiria rotear muito mais
que isso fácil. Somente observando, fiz os testes DUT1 utilizando um
testador da JDSU.
> Até mais.
> 
>> 

-- 

 

Links:
------
[1]
https://eng.registro.br/mailman/listinfo/gter