[FUG-BR] RES: freebsd 8.2 - tuning de rede

[kmkz bleh]

Luiz,

Em 15 de março de 2011 08:46, Luiz Otavio O Souza <lists.br em gmail.com>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
>