[GTER] Uso intensivo de ksoftirq no Server U L-800+Red Hat+Quagga+VRRP Keepalived.
Marcelo Gondim
gondim at bsdinfo.com.br
Fri Jun 5 16:36:06 -03 2015
On 02-06-2015 15:11, Antonio Modesto wrote:
>
>
> 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
Opa Modesto,
Eu tive vários problemas com ksoftirq no passado (2010). Na época mudei
tudo para FreeBSD e usando o mesmo hardware e nunca mais tive esse
problema de performance. Muito pelo contrário tive grandes melhoras.
Hoje nosso router de borda que roda FreeBSD + OpenBGP + full routing
segura: +2.5Gbps de link IP e 1.6Gbps de PTT folgado em um hardware
commodity. Tudo com IPv4 e IPv6.
Sei que não é recomendado mas ainda tem alguns regras de firewall
stateless com ipfw.
Nesse equipamento tem 2 portas de 10GbE SFP+ e 8 interfaces elétricas de
1GbE.
# bgpctl s s
Neighbor AS MsgRcvd MsgSent OutQ Up/Down
State/PrfRcvd
ptt_rs4v6 XXXXX 142873 43014 0 1d14h44m 1113
ptt_rs4v4 XXXXX 112877 43013 0 1d14h43m 22378
ptt_rs3v6 XXXXX 74941 43015 0 1d14h44m 1115
ptt_rs3v4 XXXXX 90175 43014 0 1d14h44m 22423
ptt_rs2v6 XXXXX 115596 43014 0 1d14h44m 1069
ptt_rs2v4 XXXXX 103833 43012 0 1d14h43m 23180
ptt_rs1v6 XXXXX 74626 43015 0 1d14h44m 1127
ptt_rs1v4 XXXXX 90452 43015 0 1d14h44m 23187
ptt_lgv6 XXXXX 49106 43015 0 1d14h44m 0
ptt_lgv4 XXXXX 48618 43015 0 1d14h43m 0
operadora2_Araruama6 XXXXX 43028 43028 0 6d04h06m 11
operadora2_Araruama XXXXX 43030 43028 0 6d04h06m 35
operadora2_Saquarema6 XXXXX 43038 43041 0 01w2d23h 5
operadora2_Saquarema XXXXX 43039 43041 0 01w2d23h 24
operadora2_Sao_Pedro6 XXXXX 43037 43043 0 01w0d18h 6
operadora2_Sao_Pedro XXXXX 43039 43041 0 01w2d23h 24
operadora2_Rio_Bonito6 XXXXX 43041 43040 0 3d06h11m 4
operadora2_Rio_Bonito XXXXX 43044 43040 0 3d06h11m 13
operadora1_Sao_Pedro6 XXXXX 43038 43041 0
01w2d23h 6
operadora1_Rio_Bonito6 XXXXX 40778 40866 0
3d05h15m 4
operadora1_Saquarema6 XXXXX 43038 43041 0
01w2d23h 5
operadora1_Araruama6 XXXXX 43028 43028 0
6d04h06m 11
operadora1_Araruama XXXXX 43030 43028 0
6d04h06m 35
operadora1_Rio_Bonito XXXXX 40829 40886 0
3d05h15m 13
operadora1_Sao_Pedro XXXXX 43039 43041 0
01w2d23h 24
operadora1_Saquarema XXXXX 43039 43041 0
01w2d23h 24
UTRS XXXXX 43239 43040 0 01w1d07h 1
cymru2 XXXXX 45571 42090 0 3d05h25m 3717/5000
cymru1 XXXXX 46254 42999 0 01w2d11h 3717/5000
facebook XXXXX 46518 43014 0 1d14h43m 23
fiat XXXXX 46489 43040 0 01w2d23h 10
operadora3_6 X.XXX 220486 43014 0 1d14h44m 21786
operadora3 X.XXX 874582 43014 0 1d14h44m 536644
operadora4_6 XXXXX 3055824 43041 0 01w2d23h 22005
operadora4 XXXXX 7699616 43041 0 01w2d23h 535276
hw.machine: amd64
hw.model: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz
hw.ncpu: 12
hw.byteorder: 1234
hw.physmem: 17083564032
hw.usermem: 12834910208
> [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.
>>
More information about the gter
mailing list