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

Sábado Janeiro 30 00:12:09 BRST 2016

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