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 -- Vinícius Zavam keybase.io/egypcio/key.asc ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
