Luiz, Em 15 de março de 2011 08:46, Luiz Otavio O Souza <[email protected]>escreveu:
> On Mar 15, 2011, at 12:28 AM, kmkz bleh wrote: > > > Pessoal, > > > > mais uma informação que acho que pode ajudar: > > > > gw# sysctl net.inet.ip.intr_queue_drops > > net.inet.ip.intr_queue_drops: 36943 > > > Esse é o número de pacotes descartados no processamento de "entrada": > Certo. > > (sys/netinet/ip_input.c) > 280 SYSCTL_PROC(_net_inet_ip, IPCTL_INTRQDROPS, intr_queue_drops, > 281 CTLTYPE_INT|CTLFLAG_RD, 0, 0, sysctl_netinet_intr_queue_drops, > "I", > 282 "Number of packets dropped from the IP input queue"); > > E que depende do tamanho máximo da fila, configurado aqui: > > # sysctl net.inet.ip.intr_queue_maxlen > net.inet.ip.intr_queue_maxlen: 256 > > (256 me parece pouco para um ambiente de alto trafego, com várias > placas/interfaces) > > Esses pacotes são enfileirados para processamento pelo 'netisr' (caso isso > ajude com os tunings...) > > O netisr tem também suas próprias filas (que eu não parei para olhar o que > cada uma faz...): > > # sysctl net.isr > net.isr.numthreads: 1 > net.isr.maxprot: 16 > net.isr.defaultqlimit: 256 > net.isr.maxqlimit: 10240 > net.isr.bindthreads: 0 > net.isr.maxthreads: 1 > net.isr.direct: 1 > net.isr.direct_force: 1 > # sysctl net.route > net.route.netisr_maxqlen: 256 > > > > > gw# vmstat -i > > interrupt total rate > > irq28: ciss0 73109 67 > > irq1: atkbd0 10 0 > > irq17: atapci0+ 242 0 > > irq22: uhci0 2 0 > > cpu0: timer 2152906 1998 > > irq256: em0 2386318 2215 > > irq257: em0 21311 19 > > irq258: em0 2 0 > > irq259: em1 665 0 > > irq260: bce0 11311742 10503 > > O rate de interrupcoes nessa placa esta bem alto, experimenta ligar o > polling nessa interface e faça alguns testes de como ela se comporta. > Exatamente. Está muito alto mesmo. Acho que já usei polling a uns tempos atrás mas parece que a situação piorou... comecei a ter mais perda de pacote. Não digo com certeza porque já faz algum tempo, mas vou ver se ativo polling denovo pra ver. A propósito, bce suporta polling? > > > > irq261: bce1 59430 55 > > irq262: em2 1954193 1814 > > irq263: em2 2460842 2284 > > irq264: em2 1 0 > > irq265: em3 6807389 6320 > > irq266: em3 6870682 6379 > > irq267: em3 14 0 > > Aqui também pode compensar... > > > irq268: bge0 1936273 1797 > > irq269: bge1 1504853 1397 > > cpu2: timer 2144394 1991 > > cpu3: timer 2144549 1991 > > cpu1: timer 2144367 1991 > > Total 43973294 40829 > > Outra coisa, vi que meu servidor deu PANIC com a msg abaixo: > > > > reboot after panic: kmem_malloc(4096): kmem_map too small: 335544320 > total > > allocated > > > > Com 4GB de RAM, o que eu devo fazer pra resolver esse problema? Qual > valor > > devo colocar no KVA_PAGES pra compilar o kernel, seria 1024? Meu kernel > ta > > compilado com a opção PAE. > > > > Só uma pergunta... você esta utilizando ZFS nesse servidor ? (esse erro > "kmem_map too small" é muito comum nessa situação, embora eu não acredite > que você esteja utilizando ZFS em um router...) > > Não faz isso não... O PAE não faz o que você pensa que ele faz... por favor > remova ele... é melhor você não aproveitar toda a memória em i386 do que > utilizar o PAE (geralmente). Fiquei com o i386 - sem PAE - ou vá para o > amd64 de vez. > > No amd64 você não terá problemas (ou no máximo, como se faz com o ZFS, será > preciso limitar o valor máximo para o kernel). > Não, não estou usando ZFS não. Eu vi mesmo que o pessoal que teve esse problema utilizava ZFS. Não é o meu caso. Vi também que tem uma sysctl pra aumentar via loader.conf, mas que pra utiliza-la precisa setar o KVA_PAGES no kernel. O problema é que mesmo sem o PAE ocorre o panic, pelo menos no FreeBSD 8.2 aconteceu... > > Att., > Luiz > ------------------------- > 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
