[FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

Quarta Março 9 12:47:01 BRT 2016

Em 04/03/2016 16:28, Vinícius Zavam escreveu:
> 2016-01-29 23:12 GMT-03:00, Marcelo Gondim <gondim em bsdinfo.com.br>:
>> Em 29/01/2016 15:16, Vinícius Zavam escreveu:
>>> 2016-01-29 13:58 GMT-03:00, Marcelo Gondim <gondim em bsdinfo.com.br>:
>>>> Em 29/01/2016 13:00, Vinícius Zavam escreveu:
>>>>> 2016-01-27 16:21 GMT-03:00, Marcelo Gondim <gondim em bsdinfo.com.br>:
>>>>>> Em 26/01/2016 19:57, Vinícius Zavam escreveu:
>>>>>>> 2016-01-24 11:18 GMT-03:00, Marcelo Gondim <gondim em bsdinfo.com.br>:
>>>>>>>> Em 14/10/2015 12:19, Marcelo Gondim escreveu:
>>>>>>>>> On 14-10-2015 06:07, Sergio Lopes wrote:
>>>>>>>>>> Estou usando o FreeBSD 10.1 com 2 interfaces de 1GB e estou com o
>>>>>>>>>> mesmo problema usando LACP
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> igb2: Interface stopped DISTRIBUTING, possible flapping
>>>>>>>>>> igb4: Interface stopped DISTRIBUTING, possible flapping
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cada vez que o problema ocorre o tráfego da interface de um
>>>>>>>>>> sentido
>>>>>>>>>> comuta para outra interface, fazendo com que o usuário perceba uma
>>>>>>>>>> queda de 5 segundos.
>>>>>>>>>>
>>>>>>>>>> Quando mudo para roundrobin e removo o lacp do FreeBSD e do Switch
>>>>>>>>>> ai
>>>>>>>>>> fica normal.
>>>>>>>>>>
>>>>>>>>> Repara também no load como que sobe. Tenta usar o 10.1-stable que
>>>>>>>>> to
>>>>>>>>> usando e vê se resolve seu problema:
>>>>>>>>>
>>>>>>>>> 10.1-STABLE r281235
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Vinícius Zavam escreveu:
>>>>>>>>>>> 2015-10-04 9:59 GMT-03:00 Marcelo Gondim<gondim em bsdinfo.com.br>:
>>>>>>>>>>>
>>>>>>> [recorte]
>>>>>>>
>>>>>>>      ...
>>>>>>>
>>>>>>> [/recorte]
>>>>>>>
>>>>>>>>>>> gondim,
>>>>>>>>>>>
>>>>>>>>>>> isso daí é algo que, assim como você, eu também teria de sentar
>>>>>>>>>>> com
>>>>>>>>>>> tempo e
>>>>>>>>>>> calma pra escovar com ajuda de ferramentas de stress, benchmark e
>>>>>>>>>>> algumas
>>>>>>>>>>> RFC; 2544, por exemplo (se não me engano).
>>>>>>>>>>>
>>>>>>>>>>> "adota essa criança" e ajuda o projeto a identificar o que está
>>>>>>>>>>> ruim
>>>>>>>>>>> pra
>>>>>>>>>>> quem utiliza stable/10. quanto mais detalhes e informações forem
>>>>>>>>>>> coletadas
>>>>>>>>>>> e reportadas, melhor. certamente uma sugestão de correção com
>>>>>>>>>>> patches
>>>>>>>>>>> também ajuda. infelizmente eu não chego nem perto de ter como
>>>>>>>>>>> reproduzir o
>>>>>>>>>>> cenário (não tenho máquinas, nem infraestrutura, que estejam
>>>>>>>>>>> disponíveis
>>>>>>>>>>> pra isso).
>>>>>>>> E ae pessoal,
>>>>>>>>
>>>>>>>> Retornando com essa thread pois descobri coisas novas à respeito do
>>>>>>>> problema. O problema não está no LACP porque nós retiramos o LACP e
>>>>>>>> colocamos tudo em interface de 10GbE X520-SR2.
>>>>>>>> O que parece é que algo mudou em relação ao cpu affinity entre a
>>>>>>>> versão
>>>>>>>> 10.1-STABLE que estou usando e as versões atuais.
>>>>>>>>
>>>>>>>> Na versão 10.1-STABLE estou com o cpu affinity assim:
>>>>>>>>
>>>>>>>> /usr/bin/cpuset -l 11 -x 300
>>>>>>>> /usr/bin/cpuset -l 10 -x 301
>>>>>>>> /usr/bin/cpuset -l 9 -x 302
>>>>>>>> /usr/bin/cpuset -l 8 -x 303
>>>>>>>> /usr/bin/cpuset -l 7 -x 304
>>>>>>>> /usr/bin/cpuset -l 6 -x 305
>>>>>>>> /usr/bin/cpuset -l 0 -x 306
>>>>>>>> /usr/bin/cpuset -l 1 -x 307
>>>>>>>> /usr/bin/cpuset -l 9 -x 308
>>>>>>>>
>>>>>>>> /usr/bin/cpuset -l 5 -x 355
>>>>>>>> /usr/bin/cpuset -l 4 -x 356
>>>>>>>> /usr/bin/cpuset -l 3 -x 357
>>>>>>>> /usr/bin/cpuset -l 2 -x 358
>>>>>>>> /usr/bin/cpuset -l 1 -x 359
>>>>>>>> /usr/bin/cpuset -l 0 -x 360
>>>>>>>> /usr/bin/cpuset -l 5 -x 361
>>>>>>>> /usr/bin/cpuset -l 4 -x 362
>>>>>>>> /usr/bin/cpuset -l 3 -x 363
>>>>>>>>
>>>>>>>> /usr/bin/cpuset -l 5 -x 364
>>>>>>>> /usr/bin/cpuset -l 4 -x 365
>>>>>>>> /usr/bin/cpuset -l 3 -x 366
>>>>>>>> /usr/bin/cpuset -l 2 -x 367
>>>>>>>> /usr/bin/cpuset -l 1 -x 368
>>>>>>>> /usr/bin/cpuset -l 0 -x 369
>>>>>>>> /usr/bin/cpuset -l 5 -x 370
>>>>>>>> /usr/bin/cpuset -l 4 -x 371
>>>>>>>> /usr/bin/cpuset -l 3 -x 372
>>>>>>>>
>>>>>>>> Dessa forma está funcionando no 10.1-STABLE sem problemas e os idle
>>>>>>>> dos
>>>>>>>> cores meio que balanceados. A máquina é um Dual Hexa Xeon e por isso
>>>>>>>> tem
>>>>>>>> 12 cores. Aí fiz uns testes e percebi o seguinte:
>>>>>>>>
>>>>>>>> Problema 1: quando atualizo do 10.1-STABLE para o 10.2 ou 11 e jogo
>>>>>>>> os
>>>>>>>> meus links para o router (+5Gbps de tráfego), os cores ficam
>>>>>>>> totalmente
>>>>>>>> desbalanceados ou seja, uns ficam normais com 30% à 40% idle e
>>>>>>>> outros
>>>>>>>> ficam com 5% à 8% idle. Isso sem mudar nada em nenhum arquivo,
>>>>>>>> somente
>>>>>>>> atualizando o sistema e mantendo todas as configurações. Egypcio
>>>>>>>> sabe
>>>>>>>> se
>>>>>>>> houve alguma mudança que poderia ter mudado esse comportamento no
>>>>>>>> cpu
>>>>>>>> affinity?
>>>>>>>>
>>>>>>>> Problema 2: no sistema atual 10.1-STABLE descobri o seguinte: fui
>>>>>>>> tentar
>>>>>>>> melhorar o balanceamento nos cores com o cpu affinity (cpuset) e
>>>>>>>> quando
>>>>>>>> faço isso passo à ter perdas de pacotes nos links de dados. O que me
>>>>>>>> obriga à ter que reiniciar o sistema pra normalizar tudo. Ou seja
>>>>>>>> mexeu
>>>>>>>> no cpu affinity, então reinicie porque senão pode dar zica e feia.
>>>>>>>>
>>>>>>>> Doideira isso. Ou seja o problema não estava no link aggregation.
>>>>>>>>
>>>>>>>> []´s
>>>>>>>> Gondim
>>>>>>> gondim,
>>>>>>> eahi. suavidade?
>>>>>>>
>>>>>>> catei aqui no histórico que tu estavas a relatar o uso da r281235
>>>>>>> como
>>>>>>> 10.1-STABLE. confere? os códigos do cpuset tu poderias verificar no
>>>>>>> "svnweb" do freebsd em https://svnweb.freebsd.org
>>>>>>> (base/stable/10/usr.bin/cpuset, se tu estás a utilizar STABLE.
>>>>>>> independente de ser 10.1, 10.2, ...); aí tu podes consultar a revisão
>>>>>>> específica. // também pode sair escovando via CLI, se quiser...
>>>>>>>
>>>>>>> em "stable/10", segundo o svnweb, não são feitas alterações nesse
>>>>>>> cabra já faz um bom tempo; 2 anos. em "releng/10.1" tu podes ver que
>>>>>>> já houve alterações mais recentes (15 meses). finalmente, em
>>>>>>> "releng/10.2", tu podes ver que o código foi alterado cerca de 6
>>>>>>> meses
>>>>>>> atrás.
>>>>>>>
>>>>>>> para qual desses branches essa tua máquina estavas/está a apontar?
>>>>>>> chegou a escovar (testar) o comportamento apenas num dos branches?
>>>>>>> fazia checkout de rHEAD ou r281235 apenas em "stable/10"? caso tu
>>>>>>> tenhas disponibilidade, experimenta utilizar rHEAD entregue pelo
>>>>>>> "releng/10.2" (se a curiosidade for ainda maior, cata os códigos da
>>>>>>> CURRENT e escova; remove DEBUG/WITNESS/INVARIANT/..., altera
>>>>>>> MALLOC_PRODUCTION, usa WITH_FAST_DEPEND, ...). vai ser divertido :3
>>>>>>>
>>>>>>> valeu por reviver essa thread!
>>>>>>>
>>>>>>> [ ]
>>>>>>>
>>>>>>>
>>>>>> HhAhAh não codo em C não. Até rodo os make da vida rsrsrsrsrsrrs mas
>>>>>> não
>>>>>> codo. Bem que queria aprender C mesmo.  :)
>>>>>> Tipo perguntei mais porque agora to seguindo um outro caminho pra
>>>>>> tentar
>>>>>> entender o problema. Depois do Carnaval vou tentar com calma atualizar
>>>>>> pro último 10-stable e refazer todo o cpu affinity de acordo como
>>>>>> estão
>>>>>> as minhas interfaces de 10GbE. Vou acompanhar o dia inteiro o seu
>>>>>> comportamento porque lá é um serviço crítico pra ficar parando pra
>>>>>> testes.
>>>>>>
>>>>>> Aí depois posto aqui o que se deu.
>>>>>>
>>>>>> []´s
>>>>>> Gondim
>>>>> se possível, faz um teste utilizando "releng/10.2" (10.2-release-p11)
>>>>> ao invés de "stable/10" (10.3-prerelease). cpuset(1) está mais
>>>>> atualizado em "releng/10.2".
>>>>>
>>>>>
>>>> Grande Egypcio,
>>>>
>>>> Cara eu acho que descobri o problema e se for isso mesmo, foi orelhada
>>>> minha na hora de fazer o cpu affinity. No troca troca de máquina e
>>>> interface pra testes eu vi agora que as interrupções estavam erradas da
>>>> ix1, ix2 e ix3. O que causaria o colapso no processamento e com isso as
>>>> perdas de pacotes devido as migrações de contextos.
>>>>
>>>> Depois do Carnaval eu vou ao Rio acertar isso e atestar essa minha
>>>> descoberta. Logo após posto aqui o resultado final. Vou usar a árvore
>>>> releng/10.2 como você sugeriu também.
>>>>
>>>> []´s
>>>> Gondim
>>> se for só isso aí, tu podes continuar com o mesmo branch que estavas a
>>> utilizar; vais cair agora na 10.3-prerelease (tu estavas a utilizar
>>> stable/10 desde o começo. correto?).
>>>
>>> [ ] ' s
>>>
>> Sim estava usando uma revisão 10.1-stable. Ainda estou  :)
>> Assim que testar lá, volto aqui para postar o resultado. Mas acho que
>> agora vai.
>>
>> []´s
> novidades?
> [ ] ' s
>
Tentei de tudo e nada ainda. Parece que tem algo à ver mesmo com o cpu 
affinity ou algo que carregue mais load nos processadores porque é 
absurda o aumento que dá de um pro outro.
Imagina o seguinte:

Com a versão 10.1-STABLE que to usando o carregamento do BGP e demais 
serviços começa com 4.0 de load e com kernels mais recentes isso sobe 
pra 9.0. No pico o meu load fica em 8.0 mas com os kernels mais recentes 
isso vai pra 20.0 de load.

Vou tentar agora com o 10.3-RC1 e ver como que vai se comportar. Uma 
coisa que não fiz foi ver se tem alguma coisa diferente que esteja no 
kernel novo e que eu não tenha compilado no meu arquivo de kernel atual. 
Você acha que foi adicionado alguma option nova nos kernels atuais que 
possam influenciar nisso?

Vou partir pra um novo teste. Não posso ficar fazendo testes o tempo 
todo porque como disse, estamos em produção com pico de quase 5Gbps de 
tráfego.

Se você quiser eu posso agendar o teste com o 10.3 no servidor de backup 
e te passar o acesso pra ver se achas algo que não to conseguindo ver. O 
que achas?
Nesse caso se der muito problema jogo de volta pro router de produção.

[]´s