[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