[FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE [PARECE QUE RESOLVEU]
Marcelo Gondim
gondim em bsdinfo.com.br
Quinta Março 10 14:56:50 BRT 2016
Em 09/03/2016 12:47, Marcelo Gondim escreveu:
> 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.
Pessoal não quero cantar vitória ainda não porque o dia é longo e
problemas podem acontecer mas coloquei o 10.3-RC1 e o load está normal
até o momento. Baixo igual estava o 10.1-STABLE.
Parece que acertaram em algum momento. Outra coisa que fiz mas não sei
se isso influenciaria foi o seguinte:
Peguei o kernel GENERIC do 10.3 e fiz um diff com o kernel que eu tava
usando e havia algumas options novas que eu adicionei nessa compilação
que fiz. Os que adicionei mas não sei se influenciou foram esses:
options RACCT # Resource accounting framework
options RACCT_DEFAULT_TO_DISABLED # Set kern.racct.enable=0 by
default
options RCTL # Resource limits
E como tenho SSD deixei esse cara aqui:
# NVM Express (NVMe) support
device nvme # base NVMe driver
device nvd # expose NVMe namespaces as
disks, depends on nvme
Vamos ver como que vai ficar até o fim do dia. :) Mas estou otimista
agora.
[]´s
Gondim
Mais detalhes sobre a lista de discussão freebsd