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

[Kalil de A. Carvalho]

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