Em 04/03/2016 16:28, Vinícius Zavam escreveu:
2016-01-29 23:12 GMT-03:00, Marcelo Gondim <gon...@bsdinfo.com.br>:
Em 29/01/2016 15:16, Vinícius Zavam escreveu:
2016-01-29 13:58 GMT-03:00, Marcelo Gondim <gon...@bsdinfo.com.br>:
Em 29/01/2016 13:00, Vinícius Zavam escreveu:
2016-01-27 16:21 GMT-03:00, Marcelo Gondim <gon...@bsdinfo.com.br>:
Em 26/01/2016 19:57, Vinícius Zavam escreveu:
2016-01-24 11:18 GMT-03:00, Marcelo Gondim <gon...@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<gon...@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
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
