Re: [FUG-BR] RES: RES: Não usem FBSD-8x como router !!!
On Mar 4, 2011, at 9:52 AM, Eduardo Schoedler wrote: Pessoal, Aproveitando o tópico... não terei perda de performance mantendo os debug symbols, KDB e GDB compilados no kernel ? Meu kernel está assim: # Debbuging makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options KDB options KDB_TRACE options GDB options SOCKBUF_DEBUG options DEBUG_VFS_LOCKS options DEBUG_MEMGUARD Sds, -- Eduardo Schoedler Eduardo, Os símbolos utilizados no debug só aumentam o tamanho do kernel, mas eles não impactam na performance do sistema pois eles não adicionam nada a mais de 'código' (não existe nada que precise ser executado 'a mais' por conta do debug). Mas isso é com relação a opção '-g'... As outras opções (kernel options) podem adicionar códigos extras de verificação (como o INVARIANTS, WITNESS, etc. - opções default no -current) e assim afetar a performance. Eu (IMHO) recomendo, ao menos, utilizar as opções que estão no kernel GENERIC (e remover as opções não default): makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options KDB # Kernel debugger related code options KDB_TRACE # Print a stack trace for a panic Já no -current, o GENERIC tem por default as seguintes opções de debug (apenas para comparação): # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones Mantendo-se próximo do GENERIC, os problemas são sempre menores (kernel padrão == recebe mais testes). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: RES: Não usem FBSD-8x como router !!!
Pessoal, Aproveitando o tópico... não terei perda de performance mantendo os debug symbols, KDB e GDB compilados no kernel ? Meu kernel está assim: # Debbuging makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options KDB options KDB_TRACE options GDB options SOCKBUF_DEBUG options DEBUG_VFS_LOCKS options DEBUG_MEMGUARD Sds, -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: RES: Não usem FBSD-8x como router !!!
Em 4 de março de 2011 09:52, Eduardo Schoedler eschoed...@viavale.com.brescreveu: Pessoal, Aproveitando o tópico... não terei perda de performance mantendo os debug symbols, KDB e GDB compilados no kernel ? Meu kernel está assim: Na prática não. Na teoria sim, pois aumenta o tamanho do kernel e executa algumas instruções desnecessárias -- printfs-like, por exemplo -- mas ajuda na hora de diagnosticar problemas. É recomendável deixar os códigos de debug. # Debbuging makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options KDB options KDB_TRACE options GDB options SOCKBUF_DEBUG options DEBUG_VFS_LOCKS options DEBUG_MEMGUARD Sds, -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: RES: Não usem FBSD-8x como router !!!
Em 02/03/2011, Klaus Schneider escreveu: Só mais uma informação, segue abaixo o link do developers handbook, lá tu vai encontrar mais informações de como manipular esses dumps. Já fiz alguma coisa, veja: Unread portion of the kernel message buffer: panic: rtfree 2 cpuid = 0 Uptime: 4m38s Physical memory: 8170 MB Dumping 566 MB: 551 535 519 503 487 471 455 439 423 407 391 375 359 343 327 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 #0 doadump () at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:224 #1 0x803ab1fa in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0x803ab601 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:592 #3 0x8046a5d5 in rtfree (rt=Variable rt is not available. ) at /usr/src/sys/net/route.c:446 #4 0x8046e178 in route_output (m=0xff00b3b02400, so=0xff00b3b32000) at /usr/src/sys/net/rtsock.c:863 #5 0x8040bc50 in sosend_generic (so=0xff00b3b32000, addr=0x0, uio=0xff8243e19aa0, top=0xff00b3b02400, control=0x0, flags=0, td=0xff00064e1000) at /usr/src/sys/kern/uipc_socket.c:1260 #6 0x803f0ebd in soo_write (fp=Variable fp is not available. ) at /usr/src/sys/kern/sys_socket.c:102 #7 0x803ea9d5 in dofilewrite (td=0xff00064e1000, fd=4, fp=0xff00064ae960, auio=0xff8243e19aa0, offset=Variable offset is not available. ) at file.h:239 #8 0x803eaca0 in kern_writev (td=0xff00064e1000, fd=4, auio=0xff8243e19aa0) at /usr/src/sys/kern/sys_generic.c:447 #9 0x803ead25 in write (td=Variable td is not available. ) at /usr/src/sys/kern/sys_generic.c:363 #10 0x803e3d20 in syscallenter (td=0xff00064e1000, sa=0xff8243e19ba0) at /usr/src/sys/kern/subr_trap.c:315 #11 0x805f50db in syscall (frame=0xff8243e19c40) at /usr/src/sys/amd64/amd64/trap.c:944 #12 0x805decb2 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:381 #13 0x000800bc5b3c in ?? () Previous frame inner to this frame (corrupt stack?) Abs, -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] RES: RES: Não usem FBSD-8x como router !!!
Em 02/03/2011 13:29, Klaus Schneider escreveu: Eduardo, tu não tem algum setup completamente diferente pra testar esse ambiente não Dell ou o IBM x3550(conheço bem esse hardware e ele nunca me dá boas lembranças... hehe)? Realmente, esse IBM não é o mesmo (ou quase) que você chegou a ver. Eles acabaram mandando outro hardware completamente novo, e dava o mesmo problema! Acabei fazendo um meio-a-meio, e não desligou mais até hoje... mas tem um problema horrível de I/O de disco, deve ser aquela controladora ServerRAID-8k (Adaptec, driver aac)... Tanto tu quanto o Renato estão tendo problemas com a igb em servidores Dell RXX. Não tenho mais nenhum hardware de grife por aqui, vou ver se monto alguma coisa para testes. A Intel ajuda o pessoal do FreeBSD a desenvolver os drivers para as placas de rede, mas entrega um firmware binário para o time de desenvolvimento. Placa física que é bom, nada ? rs. Mais um detalhe: o bgpsimple pode sim causar alguns efeitos indesejados, já que me parece um software em fase alfa, pois é apenas um projeto no google code, mal documentado que faz algumas coisas um tanto arriscadas como manipular informações de prefixos. Mesmo que ele não dê problema em no 7.X não significa que ele esteja causando o problema no 8.X. Tudo o que ele faz é identificar uma sessão eBGP ou iBGP. Se for eBGP, coloca o myas no AS_PATH e envia ao peer. Se for iBGP, encaminha como está... estou usando com -n, que seria o next-hop-self... então não vejo muito problema em injetar essas ~330k rotas no Quagga. Abs, -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: RES: Não usem FBSD-8x como router !!!
2011/3/2 Eduardo Schoedler eschoed...@viavale.com.br Em 02/03/2011 13:29, Klaus Schneider escreveu: Eduardo, tu não tem algum setup completamente diferente pra testar esse ambiente não Dell ou o IBM x3550(conheço bem esse hardware e ele nunca me dá boas lembranças... hehe)? Realmente, esse IBM não é o mesmo (ou quase) que você chegou a ver. Eles acabaram mandando outro hardware completamente novo, e dava o mesmo problema! Acabei fazendo um meio-a-meio, e não desligou mais até hoje... mas tem um problema horrível de I/O de disco, deve ser aquela controladora ServerRAID-8k (Adaptec, driver aac)... Tanto tu quanto o Renato estão tendo problemas com a igb em servidores Dell RXX. Não tenho mais nenhum hardware de grife por aqui, vou ver se monto alguma coisa para testes. A Intel ajuda o pessoal do FreeBSD a desenvolver os drivers para as placas de rede, mas entrega um firmware binário para o time de desenvolvimento. Placa física que é bom, nada ? rs. Se eles mandam a placa pra equipe? É claro que sim, mas firmware depende somente do fabricante e da vontade deles, e esses hardwares estão ficando cada vez mais complexos, fica cada vez mais difícil fazer engenharia reversa destes dispositivos, quando isso não se torna um problema legal pela quebra de patente. Mais um detalhe: o bgpsimple pode sim causar alguns efeitos indesejados, já que me parece um software em fase alfa, pois é apenas um projeto no google code, mal documentado que faz algumas coisas um tanto arriscadas como manipular informações de prefixos. Mesmo que ele não dê problema em no 7.X não significa que ele esteja causando o problema no 8.X. Tudo o que ele faz é identificar uma sessão eBGP ou iBGP. Se for eBGP, coloca o myas no AS_PATH e envia ao peer. Se for iBGP, encaminha como está... estou usando com -n, que seria o next-hop-self... então não vejo muito problema em injetar essas ~330k rotas no Quagga. Um bit pode causar um overflow. Não sou desenvolvedor, mas da pra imaginar que isso pode acontecer, principalmente se o quagga aceitar uma informação mal repassada que vai parar dentro do kernel, não fica reservado ao userland. Talvez nem seja problema com o bgpsimple, pode ser com o quagga. Imagino que teu trabalho não seja ficar só brincando de setup de testes, mas já que passou tanto tempo, dedicar mais algumas horas não vai fazer tanta diferença. Já testou o bgpsimple com o openbgpd ou i386(citado pelo Patrik)? Para finalizar: flames acontecem, principalmente se mandar essa mensagem para um grupo de usuários de um sistema falando que ele é ruim. Experimente mandar um email para o postfix-br com o assunto Não usem Postfix 2.8!!! e que vai migrar para o Qmail. Comparado ao que iria acontecer se falasse isso lá, da pra dizer que aqui praticamente não houveram flames. Abs, -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- /* * Klaus Schneider */ - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
