[FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE
Vinícius Zavam
egypcio em googlemail.com
Sexta Março 4 16:28:18 BRT 2016
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
--
Vinícius Zavam
keybase.io/egypcio/key.asc
Mais detalhes sobre a lista de discussão freebsd