[GTER] Uso intensivo de ksoftirq no Server U L-800+Red Hat+Quagga+VRRP Keepalived.
Noilson Caio
caiogore at gmail.com
Tue Jun 2 11:07:46 -03 2015
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
--
Noilson Caio Teixeira de Araújo
https://ncaio.wordpress.com
https://br.linkedin.com/in/ncaio
https://twitter.com/noilsoncaio
https://jammer4.com
http://8bit.academy
More information about the gter
mailing list