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

2011-03-15 Por tôpico Luiz Otavio O Souza
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:

(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: em021311 19
 irq258: em02  0
 irq259: em1  665  0
 irq260: bce011311742  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.


 irq261: bce1   59430 55
 irq262: em2  1954193   1814
 irq263: em2  2460842   2284
 irq264: em21  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).

Att.,
Luiz
-
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: freebsd 8.2 - tuning de rede

2011-03-15 Por tôpico kmkz bleh
Luiz,

Em 15 de março de 2011 08:46, Luiz Otavio O Souza lists...@gmail.comescreveu:

 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: em021311 19
  irq258: em02  0
  irq259: em1  665  0
  irq260: bce011311742  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: em21  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


Re: [FUG-BR] php_module_shutdown_wrapper

2011-03-15 Por tôpico Helizonaldo Alves de Morais

Olá a todos 

Para quem passar por isso consegui resolver o problema setando essa TAG e logo 
em seguida recompilando o Apache e o PHP.
setenv CFLAGS -DAMD64 -fPIC


grato


Helizonaldo Alves de Morais 
Teresina-PI Brasil.  
+-+
 
 
 Boa tarde a todos
 Instalei o PHP 5.3.5   com  o Apache/2.2.17  no  FreeBSD 8.1-RELEASE 
 amd64 64bit mas quando vou levantar o Apache ele da o seguinte erro:
 Syntax error on line 56 of /usr/local/apache2/conf/httpd.conf: Cannot load 
 /usr/local/apache2/modules/libphp5.so into server: 
 /usr/local/apache2/modules/libphp5.so: Undefined symbol 
 php_module_shutdown_wrapper
 
 sempre instalei o PHP com o Apache e nunca tive esse tipo de erro, alguém 
 pode me ajudar?
 grato
 
 
 Helizonaldo Alves de Morais 
 Teresina-PI Brasil.  
 +-+
 
 -
 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] samsung ml1665

2011-03-15 Por tôpico washington de lima
Bom dia pessoal.Alguém sabe me dizerse o freebsd está suportandoa impressora 
samsung ml 1665.Estou querendo comprar uma, eno momento estou atualizando omeu 
sistema para versão 7.4do free.Desde já agradeço por qualquerinformação.
Washington de Lima


  
-
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: freebsd 8.2 - tuning de rede

2011-03-15 Por tôpico Eduardo Schoedler
Em 15/03/2011 09:24, kmkz bleh escreveu:
 A propósito, bce suporta polling?

As minhas não.

# dmesg | grep bce
bce0: Broadcom NetXtreme II BCM5716 1000Base-T (C0) mem
0xd800-0xd9ff irq 16 at device 0.0 on pci5

# ifconfig -m bce0
bce0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 
capabilities=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCS
UM,TSO4,VLAN_HWTSO,LINKSTATE

Já tentou colocar uma placa de rede Intel nesse servidor ?
Não gosto dessas Broadcom, em testes com iperf o desempenho delas nem
chegava perto de ~900Mbps, coisa que as Intel fazia tranquilamente.

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] samsung ml1665

2011-03-15 Por tôpico Eduardo Lemos de Sa
Oi Washington

Não sei te dizer em particular para esta impressora, mas eu tenho uma
Samsung 4200CXS (multifucional) e vasculhei o mundo atrás de drivers (mesmo
os para linuxes já interessavam): nada encontrei. Pelo suporte da Samsung,
recebi a informação de que eles não dão e nem pretendem (política estranha
essa) fazer drivers para sistemas Unixes. Não querendo fazer propaganda,
esta política é claramente oposta à empregada pela HP.

Edu




2011/3/15 washington de lima mecanicaestatist...@yahoo.com.br

 Bom dia pessoal.Alguém sabe me dizerse o freebsd está suportandoa
 impressora samsung ml 1665.Estou querendo comprar uma, eno momento estou
 atualizando omeu sistema para versão 7.4do free.Desde já agradeço por
 qualquerinformação.
 Washington de Lima



 -
 Histórico: http://www.fug.com.br/historico/html/freebsd/
 Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd




-- 
Eduardo Lemos de Sa
Associated Professor Level 2
Dep. Quimica da Universidade Federal do Paraná
fone: +55(41)3361-3300
fax:   +55(41)3361-3186
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


[FUG-BR] ATENCAO - Regras da Lista - LEMBRETE

2011-03-15 Por tôpico Charlie Root (DevilBit Super User)
Esta é uma mensagem automática, enviada periodicamente para a lista
como lembrete de quais são e onde encontrar as regras de boa conduta.

Para bom uso desta lista, É fundamental que você tenha lido, compreendido
e concordado com as regras. Caso ainda nao as tenha lido, reserve um
tempinho para esta tarefa.

Para evitar a inclusão das regras neste e-mail e poupar alguns kilobytes 
mensais repetitivos em Vssa. caixa postal, este lembrete refere-se
apenas à URL onde encontrar as regras:

https://www.fug.com.br/mailman/listinfo/freebsd

Conheça-as, por gentileza.

--
FUG-BR: Grupo Brasileiro de Usuarios de FreeBSD
Desde 1999, espalhando o BSD
http://www.fug.com.br
adm...@fug.com.br

-
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: pfSense - Brigde Transparente

2011-03-15 Por tôpico Paulo Henrique BSD Brasil
Em 14/3/2011 18:41, Eduardo Schoedler escreveu:
 Poderia ainda ter criado uma regra de NO NAT.
 Mas como dizem por aí: quanto menos regras, melhor! :-)

 Chegou a notar diferença entre um firewall roteado e um bridge ?
 Consumo de CPU... latência... etc.

 Abs.

 --
 Eduardo Schoedler
Esta ai umas duvidas que tenho, porem sem ambiente para poder saná-las.
Até hoje configurei sempre o firewall sendo um dispositivo junto ao 
roteador e em alguns casos pertencendo ao roteador de gerenciamento de 
trafego (dummynet ),
Se alguém que tem esse ambiente poder disponibilizar informações quanto 
ao comportamento de dispositivo de filtragem na bridge seria de grande 
valia para muitos aqui e enriqueceria o histórico da lista 
consideravelmente.

Att, e se poder disponibilizar tais informações ao menos eu estarei 
agradecido.



 -Mensagem original-
 De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em
 nome de Luan Tasca
 Enviada em: segunda-feira, 14 de março de 2011 18:39
 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
 Assunto: Re: [FUG-BR] RES: pfSense - Brigde Transparente

 Em 14-03-2011 18:13, Eduardo Schoedler escreveu:
 Em 14/03/2011 17:13,  Luan Tasca escreveu:
 pra sair, os servidores em vez de usar os ips 10.0.0.x
 cada um com seu ip, está saindo com o ip 10.0.0.2, que é
 o ip do pfsense, mais preciso que cada servidor saia
 com seu ip, alguem sabe como arrumo isso?
 o PFSense deve estar fazendo NAT... ou então você está com proxy
 ativado.
 --
 Eduardo Schoedler
 Consegui fazer funcionar, pra ficar documentado e se alguem passar por
 isso..

 Firewall: NAT: Outbound

 Ativar *Manual Outbound NAT rule generation (Advanced Outbound NAT
 (AON))

 *e apagar a regra que ele cria sozinho.

 --
 Luan Tasca
 luanta...@gmail.com
 -
 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


Re: [FUG-BR] samsung ml1665

2011-03-15 Por tôpico washington de lima
Olá Edu.Valeu pela informação agora vou analisar a opção de uma HP mesmo.
Um abraço
Washington de Lima




  
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd