Re: [FUG-BR] RES: freebsd 8.2 - tuning de rede
On Mar 15, 2011, at 9:24 AM, kmkz bleh wrote: 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? É... a bce não suporta polling... porém há uma luz no fim do tunel.. parece que tem um firmware novo disponível para ela. A má noticia é que isso só esta disponível no -current, mas você pode copiar os drivers na mão para o 8-stable (ou 8-release tanto faz..): cp /current/src/sys/dev/bce/* /stable/src/sys/dev/bce (isso vai acontecer naturalmente como parte do processo de desenvolvimento - mas não tem dia para acontecer). Uma outra coisa que importante para redes gigabit é _NUNCA_ (repito NUNCA) force a velocidade nessas portas. As interfaces gigabit PRECISAM da auto-negociação ativa para o correto funcionamento. O formato dessas interfaces é diferente das antigas 10/100 que geralmente funcionavam melhor com velocidades fixas. Na portas gigabit há necessidade que uma ponta seja nomeada como MASTER e a outra ponta SLAVE e nem todos drivers suportam essas configurações feitas manualmente. Se sua conexão gigabit não funciona em 'autoselect' você tem algum 'outro' problema ai (cabos, a própria interface de rede, switches, etc.). Voltando a bce, aqui esta uma lista das ultimas correções nesse driver: r218529 | davidch | 2011-02-10 22:41:49 -0200 (Thu, 10 Feb 2011) | 4 lines - Updated firmware which improves small packet performance. MFC after: 2 weeks r218527 | davidch | 2011-02-10 20:36:23 -0200 (Thu, 10 Feb 2011) | 6 lines - Added error checking to nvram read functions. - Minor style updates. Submitted by: gcoo...@freebsd.org MFC after: 2 weeks r218423 | davidch | 2011-02-07 21:00:24 -0200 (Mon, 07 Feb 2011) | 12 lines - Added systcls for header splitting, RX/TX buffer count, interrupt coalescing, strict RX MTU, verbose output, and shared memory debug. - Added additional debug counters (VLAN tags and split header frames). - Updated debug counters to 64 bit definitions. - Updated l2fhdr bit definitions. - Combined RX buffer sizing into a single function. - Added buffer size and interrupt coalescing settings to adapter info printout. Submitted by: davidch MFC after: 2 weeks [snip] 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).
Re: [FUG-BR] RES: freebsd 8.2 - tuning de rede
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
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] RES: freebsd 8.2 - tuning de rede
Já troquei. Coloquei o CMTS ligado na placa Intel (em1) e mesmo assim o desempenho é ruim. Depois do servidor travar constantemente este final de semana, instalei o FreeBSD 7.4 nesta madrugada. Infelizmente por ser um ambiente de produção com milhares de usuários não posso ficar fazendo testes, e a máquina também está alguns kilometros de distância o que dificulta ainda mais. Uma das coisas que eu vi e já resolvi é a questão da perda de pacote do CMTS para o FreeBSD. O pessoal mandava 1000 pacotes e o kernel tem limite de 200 pacotes por segurança. Deixando como 0 essa perda parou. Quando desabilito a opção net.isr.direct eu também quase não tenho perda só que a latencia ta alta. Por exemplo: PING 10.20.0.2 (10.20.0.2): 56 data bytes 64 bytes from 10.20.0.2: icmp_seq=0 ttl=255 time=0.439 ms 64 bytes from 10.20.0.2: icmp_seq=1 ttl=255 time=0.285 ms 64 bytes from 10.20.0.2: icmp_seq=2 ttl=255 time=0.280 ms 64 bytes from 10.20.0.2: icmp_seq=3 ttl=255 time=0.492 ms 64 bytes from 10.20.0.2: icmp_seq=4 ttl=255 time=0.257 ms 64 bytes from 10.20.0.2: icmp_seq=5 ttl=255 time=0.302 ms 64 bytes from 10.20.0.2: icmp_seq=6 ttl=255 time=0.342 ms 64 bytes from 10.20.0.2: icmp_seq=7 ttl=255 time=0.266 ms [snip] 64 bytes from 10.20.0.2: icmp_seq=17 ttl=255 time=79.075 ms 64 bytes from 10.20.0.2: icmp_seq=18 ttl=255 time=12.466 ms 64 bytes from 10.20.0.2: icmp_seq=19 ttl=255 time=45.409 ms 64 bytes from 10.20.0.2: icmp_seq=20 ttl=255 time=45.705 ms 64 bytes from 10.20.0.2: icmp_seq=21 ttl=255 time=7.613 ms 64 bytes from 10.20.0.2: icmp_seq=22 ttl=255 time=7.436 ms 64 bytes from 10.20.0.2: icmp_seq=23 ttl=255 time=7.609 ms 64 bytes from 10.20.0.2: icmp_seq=24 ttl=255 time=7.541 ms [snip] 64 bytes from 10.20.0.2: icmp_seq=28 ttl=255 time=113.203 ms [snip] 64 bytes from 10.20.0.2: icmp_seq=36 ttl=255 time=8.471 ms 64 bytes from 10.20.0.2: icmp_seq=37 ttl=255 time=12.514 ms 64 bytes from 10.20.0.2: icmp_seq=38 ttl=255 time=24.049 ms 64 bytes from 10.20.0.2: icmp_seq=39 ttl=255 time=66.910 ms 64 bytes from 10.20.0.2: icmp_seq=40 ttl=255 time=88.233 ms ^C --- 10.20.0.2 ping statistics --- 41 packets transmitted, 41 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.226/18.730/113.203/27.405 ms Repare que não houve perdas de pacote, mas o tempo de resposta variou muito, tendo pico de 113ms. Se eu cancelo o ping e mando outro, começa novamente abaixo de 1ms até aumentar o tempo de resposta. Preciso saber se existe alguma coisa que eu possa fazer em termos de tuning pra que esse valor fique na faixa de 1ms, já que está ligado diretamente, sem switch no meio. (mesmo com switch o problema persiste). E uma vez o tempo de resposta alto, ele não volta novamente na casa de 1ms ou menor que 1ms. Mas se dispara outro ping, começa novamente em menor que 1ms. Outra coisa, deixei somente o pf habilitado. O kernel resolvi compilar sem o ipfw/dummynet pra ver se iria mudar alguma coisa no desempenho. Mesmo deixando controle de banda so pra rede interna (192.168.0.0/24). Em 11 de março de 2011 17:52, mantunes mantunes.lis...@gmail.com escreveu: existe possibilidade de trocar a placa de rede, porta do Switch.. Em 11 de março de 2011 17:41, kmkz bleh jsi...@gmail.com escreveu: Já verifiquei o CMTS sim... não vi nada errado nele. O negócio é que quando passa pelo servidor ou perde pacote ou a latência fica muito alta. Por exemplo, o ping de uma estação na outra, so switch msm, o tempo é menor que 1 ms. Quando pinga o servidor já apresenta perda ou o tempo fica na casa de 4 ms (rede interna) com picos de 20, 30, 50 ms. Em 11 de março de 2011 17:08, Edinilson - ATINET edinil...@atinet.com.brescreveu: Baseado neste problema (e outros similares), gostaria de perguntar aos experts em Freebsd da lista: nos casos como este, faz diferença o scheduler que está sendo utilizado? Se sim, qual o melhor? No Freebsd 8, ainda está vindo como padrao o bom e velho 4BSD ou já vem o ULE? Obrigado Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: kmkz bleh jsi...@gmail.com To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Friday, March 11, 2011 3:48 PM Subject: Re: [FUG-BR] RES: freebsd 8.2 - tuning de rede - 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 -- Marcio Antunes Powered by FreeBSD == * Windows: Where do you want to go tomorrow? * Linux: Where do you want to go today? * FreeBSD: Are you, guys, comming or what? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da
Re: [FUG-BR] RES: freebsd 8.2 - tuning de rede
, porta do Switch.. Em 11 de março de 2011 17:41, kmkz bleh jsi...@gmail.com escreveu: Já verifiquei o CMTS sim... não vi nada errado nele. O negócio é que quando passa pelo servidor ou perde pacote ou a latência fica muito alta. Por exemplo, o ping de uma estação na outra, so switch msm, o tempo é menor que 1 ms. Quando pinga o servidor já apresenta perda ou o tempo fica na casa de 4 ms (rede interna) com picos de 20, 30, 50 ms. Em 11 de março de 2011 17:08, Edinilson - ATINET edinil...@atinet.com.brescreveu: Baseado neste problema (e outros similares), gostaria de perguntar aos experts em Freebsd da lista: nos casos como este, faz diferença o scheduler que está sendo utilizado? Se sim, qual o melhor? No Freebsd 8, ainda está vindo como padrao o bom e velho 4BSD ou já vem o ULE? Obrigado Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: kmkz bleh jsi...@gmail.com To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Friday, March 11, 2011 3:48 PM Subject: Re: [FUG-BR] RES: freebsd 8.2 - tuning de rede - 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 -- Marcio Antunes Powered by FreeBSD == * Windows: Where do you want to go tomorrow? * Linux: Where do you want to go today? * FreeBSD: Are you, guys, comming or what? - 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: freebsd 8.2 - tuning de rede
Chegou a desabilitar o PF para testar ?
-Mensagem original-
De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em
nome de kmkz bleh
Enviada em: sexta-feira, 11 de março de 2011 11:22
Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
Assunto: Re: [FUG-BR] freebsd 8.2 - tuning de rede
O cabo é um CAT6 blindado. Não sei como está o cabo porque estou a kms
de
distancia desta operação.
Vou colocar mais algumas informações:
gw# netstat -nm
6395/2950/9345 mbufs in use (current/cache/total)
6393/3037/9430/2097152 mbuf clusters in use (current/cache/total/max)
6392/2184 mbuf+clusters out of packet secondary zone in use
(current/cache)
0/0/0/12800 4k (page size) jumbo clusters in use
(current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
14400K/6811K/21212K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/6/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines
Deixei o nmbclusters com esse valor:
kern.ipc.nmbclusters=2097152
gw# limits
Resource limits (current):
cputime infinity secs
filesize infinity kB
datasize 524288 kB
stacksize 65536 kB
coredumpsize infinity kB
memoryuseinfinity kB
memorylocked infinity kB
maxprocesses 5547
openfiles 11095
sbsize infinity bytes
vmemoryuse infinity kB
pseudo-terminals infinity
swapuse infinity kB
gw# vmstat -z
ITEM SIZE LIMIT USED FREE REQUESTS
FAILURES
mbuf_packet: 256,0, 6400, 2176,
351387694,0
mbuf: 256,0,4, 765,
502813275,0
mbuf_cluster:2048, 2097152, 8577, 853,
145329250,0
mbuf_jumbo_page: 4096,12800,0,0,
0,0
mbuf_jumbo_9k: 9216, 6400,0,0,
0,0
mbuf_jumbo_16k: 16384, 3200,0,0,
0,0
mbuf_ext_refcnt:4,0,0, 406,
3,0
pf.conf:
set limit { states 100, frags 10 }
set optimization normal
scrub in all
-
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
Eduardo,
parece que houve uma melhora depois que desativei o PF:
--- 10.20.0.2 ping statistics ---
127 packets transmitted, 127 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.163/0.289/0.678/0.067 ms
--- 10.20.0.2 ping statistics ---
109 packets transmitted, 109 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.166/0.313/2.107/0.218 ms
--- 10.20.0.2 ping statistics ---
102 packets transmitted, 102 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.138/0.382/9.108/0.874 ms
Em 11 de março de 2011 11:24, Eduardo Schoedler
eschoed...@viavale.com.brescreveu:
Chegou a desabilitar o PF para testar ?
-Mensagem original-
De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em
nome de kmkz bleh
Enviada em: sexta-feira, 11 de março de 2011 11:22
Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
Assunto: Re: [FUG-BR] freebsd 8.2 - tuning de rede
O cabo é um CAT6 blindado. Não sei como está o cabo porque estou a kms
de
distancia desta operação.
Vou colocar mais algumas informações:
gw# netstat -nm
6395/2950/9345 mbufs in use (current/cache/total)
6393/3037/9430/2097152 mbuf clusters in use (current/cache/total/max)
6392/2184 mbuf+clusters out of packet secondary zone in use
(current/cache)
0/0/0/12800 4k (page size) jumbo clusters in use
(current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
14400K/6811K/21212K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/6/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines
Deixei o nmbclusters com esse valor:
kern.ipc.nmbclusters=2097152
gw# limits
Resource limits (current):
cputime infinity secs
filesize infinity kB
datasize 524288 kB
stacksize 65536 kB
coredumpsize infinity kB
memoryuseinfinity kB
memorylocked infinity kB
maxprocesses 5547
openfiles 11095
sbsize infinity bytes
vmemoryuse infinity kB
pseudo-terminals infinity
swapuse infinity kB
gw# vmstat -z
ITEM SIZE LIMIT USED FREE REQUESTS
FAILURES
mbuf_packet: 256,0, 6400, 2176,
351387694,0
mbuf: 256,0,4, 765,
502813275,0
mbuf_cluster:2048, 2097152, 8577, 853,
145329250,0
mbuf_jumbo_page: 4096,12800,0,0,
0,0
mbuf_jumbo_9k: 9216, 6400,0,0,
0,0
mbuf_jumbo_16k: 16384, 3200,0,0,
0,0
mbuf_ext_refcnt:4,0,0, 406,
3,0
pf.conf:
set limit { states 100, frags 10 }
set optimization normal
scrub in all
-
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] RES: freebsd 8.2 - tuning de rede
Você chegou a testar com o ping -f para ver a real perda de pacotes? root@freud rafaelhfaria # ifconfig lagg0 lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:1f:29:58:ee:b2 inet 172.30.0.1 netmask 0x broadcast 172.30.255.255 inet6 fe80::21f:29ff:fe58:eeb2%lagg0 prefixlen 64 scopeid 0x6 nd6 options=3PERFORMNUD,ACCEPT_RTADV media: Ethernet autoselect status: active laggproto lacp laggport: em2 flags=1cACTIVE,COLLECTING,DISTRIBUTING laggport: em1 flags=1cACTIVE,COLLECTING,DISTRIBUTING laggport: em0 flags=1cACTIVE,COLLECTING,DISTRIBUTING root@freud rafaelhfaria # ping -f 172.30.1.1 PING 172.30.1.1 (172.30.1.1): 56 data bytes ..^C. --- 172.30.1.1 ping statistics --- 398758 packets transmitted, 398756 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.060/0.108/11.330/0.038 ms root@freud rafaelhfaria # Perdendo 2 pacotes entre quase 400 mil pacotes, acredito que seja aceitável. Porém no meu caso, tenho um Switch D-Link DGS-3100 no meio, e apenas esta máquina está usando Link Aggregation. A outra possui apenas uma conexão com o switch. -- Rafael Henrique da Silva Faria - 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
Outra coisa que estou vendo, é que além dos pacotes perdidos, ainda tenho ping: sendto: No buffer space available Mas já aumentei muito o kern.ipc.nmbclusters (no momento deixei 4194304). gw-ija# netstat -nm 6521/3724/10245 mbufs in use (current/cache/total) 6517/3713/10230/4194304 mbuf clusters in use (current/cache/total/max) *6516/2956 mbuf+clusters out of packet secondary zone in use (current/cache) * 0/0/0/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 14688K/8357K/23045K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/6/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Mas não esta fazendo efeito... Em 11 de março de 2011 11:59, Rafael Henrique Faria rafaelhfa...@cenadigital.com.br escreveu: Você chegou a testar com o ping -f para ver a real perda de pacotes? root@freud rafaelhfaria # ifconfig lagg0 lagg0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4 ether 00:1f:29:58:ee:b2 inet 172.30.0.1 netmask 0x broadcast 172.30.255.255 inet6 fe80::21f:29ff:fe58:eeb2%lagg0 prefixlen 64 scopeid 0x6 nd6 options=3PERFORMNUD,ACCEPT_RTADV media: Ethernet autoselect status: active laggproto lacp laggport: em2 flags=1cACTIVE,COLLECTING,DISTRIBUTING laggport: em1 flags=1cACTIVE,COLLECTING,DISTRIBUTING laggport: em0 flags=1cACTIVE,COLLECTING,DISTRIBUTING root@freud rafaelhfaria # ping -f 172.30.1.1 PING 172.30.1.1 (172.30.1.1): 56 data bytes ..^C. --- 172.30.1.1 ping statistics --- 398758 packets transmitted, 398756 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.060/0.108/11.330/0.038 ms root@freud rafaelhfaria # Perdendo 2 pacotes entre quase 400 mil pacotes, acredito que seja aceitável. Porém no meu caso, tenho um Switch D-Link DGS-3100 no meio, e apenas esta máquina está usando Link Aggregation. A outra possui apenas uma conexão com o switch. -- Rafael Henrique da Silva Faria - 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
On Mar 11, 2011, at 12:06 PM, kmkz bleh wrote: Outra coisa que estou vendo, é que além dos pacotes perdidos, ainda tenho ping: sendto: No buffer space available Mas já aumentei muito o kern.ipc.nmbclusters (no momento deixei 4194304). gw-ija# netstat -nm 6521/3724/10245 mbufs in use (current/cache/total) 6517/3713/10230/4194304 mbuf clusters in use (current/cache/total/max) *6516/2956 mbuf+clusters out of packet secondary zone in use (current/cache) * 0/0/0/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 14688K/8357K/23045K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/6/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Mas não esta fazendo efeito... Nesse caso voce tem que aumentar o tamanho da fila de envio da interface (que por padrão é bem pequena no FreeBSD para determinadas aplicações): # sysctl net.link.ifqmaxlen net.link.ifqmaxlen: 50 Note que essa é uma variável que precisa ser configurada via loader (/boot/loader.conf) e que vale para todas interfaces do sistema. Eu tentaria algo como 128~256 para começar, mas se você procurar na net, vai encontrar valores bem maiores aqui (até 4096 ?). 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
Certo Luiz, vou tentar com 256 nesta sysctl e vê o resultado. Eduardo, fazendo o ping conforme você havia falado: gw# sysctl net.inet.icmp.icmplim=0 net.inet.icmp.icmplim: 200 - 0 gw# ping -s 1400 -i 0.02 -c 1000 -q 10.20.0.2 PING 10.20.0.2 (10.20.0.2): 1400 data bytes --- 10.20.0.2 ping statistics --- 1000 packets transmitted, 996 packets received, 0.4% packet loss round-trip min/avg/max/stddev = 0.206/0.512/21.723/1.287 ms gw# ping -s 1400 -i 0.02 -c 1000 -q 10.20.0.2 PING 10.20.0.2 (10.20.0.2): 1400 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available --- 10.20.0.2 ping statistics --- 1000 packets transmitted, 994 packets received, 0.6% packet loss round-trip min/avg/max/stddev = 0.200/0.466/16.629/0.936 ms - 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
Eduardo, depois de desativar a sysctl net.isr.direct notei que as perdas pararam... apesar do tempo de resposta ainda continuar bastante alto. Só de não estar havendo perda, já é um ótimo sinal, apesar que ainda tenho que ver o porque do tempo de resposta variar tanto e apresentar valores mto alto, o que ao meu ver, não é normal. 64 bytes from 10.20.0.2: icmp_seq=5 ttl=255 time=0.292 ms 64 bytes from 10.20.0.2: icmp_seq=6 ttl=255 time=0.427 ms 64 bytes from 10.20.0.2: icmp_seq=7 ttl=255 time=0.294 ms 64 bytes from 10.20.0.2: icmp_seq=8 ttl=255 time=0.418 ms 64 bytes from 10.20.0.2: icmp_seq=9 ttl=255 time=0.318 ms 64 bytes from 10.20.0.2: icmp_seq=10 ttl=255 time=53.773 ms 64 bytes from 10.20.0.2: icmp_seq=11 ttl=255 time=9.912 ms 64 bytes from 10.20.0.2: icmp_seq=12 ttl=255 time=40.202 ms 64 bytes from 10.20.0.2: icmp_seq=13 ttl=255 time=40.065 ms 64 bytes from 10.20.0.2: icmp_seq=14 ttl=255 time=5.428 ms 64 bytes from 10.20.0.2: icmp_seq=15 ttl=255 time=6.929 ms 64 bytes from 10.20.0.2: icmp_seq=16 ttl=255 time=6.128 ms 64 bytes from 10.20.0.2: icmp_seq=17 ttl=255 time=7.662 ms 64 bytes from 10.20.0.2: icmp_seq=18 ttl=255 time=7.105 ms 64 bytes from 10.20.0.2: icmp_seq=19 ttl=255 time=17.751 ms 64 bytes from 10.20.0.2: icmp_seq=20 ttl=255 time=42.590 ms 64 bytes from 10.20.0.2: icmp_seq=21 ttl=255 time=100.127 ms 64 bytes from 10.20.0.2: icmp_seq=22 ttl=255 time=22.628 ms 64 bytes from 10.20.0.2: icmp_seq=23 ttl=255 time=19.604 ms ^C --- 10.20.0.2 ping statistics --- 24 packets transmitted, 24 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.284/16.054/100.127/23.547 ms Em 11 de março de 2011 14:01, kmkz bleh jsi...@gmail.com escreveu: Certo Luiz, vou tentar com 256 nesta sysctl e vê o resultado. Eduardo, fazendo o ping conforme você havia falado: gw# sysctl net.inet.icmp.icmplim=0 net.inet.icmp.icmplim: 200 - 0 gw# ping -s 1400 -i 0.02 -c 1000 -q 10.20.0.2 PING 10.20.0.2 (10.20.0.2): 1400 data bytes --- 10.20.0.2 ping statistics --- 1000 packets transmitted, 996 packets received, 0.4% packet loss round-trip min/avg/max/stddev = 0.206/0.512/21.723/1.287 ms gw# ping -s 1400 -i 0.02 -c 1000 -q 10.20.0.2 PING 10.20.0.2 (10.20.0.2): 1400 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available --- 10.20.0.2 ping statistics --- 1000 packets transmitted, 994 packets received, 0.6% packet loss round-trip min/avg/max/stddev = 0.200/0.466/16.629/0.936 ms - 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
Rapaz, vc testou o CMTS ? é somente para este servidor com freebsd, tem alguma maquina linux ou windows ??? estranho esse problema.. -- Marcio Antunes - 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
Baseado neste problema (e outros similares), gostaria de perguntar aos experts em Freebsd da lista: nos casos como este, faz diferença o scheduler que está sendo utilizado? Se sim, qual o melhor? No Freebsd 8, ainda está vindo como padrao o bom e velho 4BSD ou já vem o ULE? Obrigado Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: kmkz bleh jsi...@gmail.com To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Friday, March 11, 2011 3:48 PM Subject: Re: [FUG-BR] RES: freebsd 8.2 - tuning de rede - 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
Já verifiquei o CMTS sim... não vi nada errado nele. O negócio é que quando passa pelo servidor ou perde pacote ou a latência fica muito alta. Por exemplo, o ping de uma estação na outra, so switch msm, o tempo é menor que 1 ms. Quando pinga o servidor já apresenta perda ou o tempo fica na casa de 4 ms (rede interna) com picos de 20, 30, 50 ms. Em 11 de março de 2011 17:08, Edinilson - ATINET edinil...@atinet.com.brescreveu: Baseado neste problema (e outros similares), gostaria de perguntar aos experts em Freebsd da lista: nos casos como este, faz diferença o scheduler que está sendo utilizado? Se sim, qual o melhor? No Freebsd 8, ainda está vindo como padrao o bom e velho 4BSD ou já vem o ULE? Obrigado Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: kmkz bleh jsi...@gmail.com To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Friday, March 11, 2011 3:48 PM Subject: Re: [FUG-BR] RES: freebsd 8.2 - tuning de rede - 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] RES: freebsd 8.2 - tuning de rede
existe possibilidade de trocar a placa de rede, porta do Switch.. Em 11 de março de 2011 17:41, kmkz bleh jsi...@gmail.com escreveu: Já verifiquei o CMTS sim... não vi nada errado nele. O negócio é que quando passa pelo servidor ou perde pacote ou a latência fica muito alta. Por exemplo, o ping de uma estação na outra, so switch msm, o tempo é menor que 1 ms. Quando pinga o servidor já apresenta perda ou o tempo fica na casa de 4 ms (rede interna) com picos de 20, 30, 50 ms. Em 11 de março de 2011 17:08, Edinilson - ATINET edinil...@atinet.com.brescreveu: Baseado neste problema (e outros similares), gostaria de perguntar aos experts em Freebsd da lista: nos casos como este, faz diferença o scheduler que está sendo utilizado? Se sim, qual o melhor? No Freebsd 8, ainda está vindo como padrao o bom e velho 4BSD ou já vem o ULE? Obrigado Edinilson - ATINET-Professional Web Hosting Tel Voz: (0xx11) 4412-0876 http://www.atinet.com.br - Original Message - From: kmkz bleh jsi...@gmail.com To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) freebsd@fug.com.br Sent: Friday, March 11, 2011 3:48 PM Subject: Re: [FUG-BR] RES: freebsd 8.2 - tuning de rede - 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 -- Marcio Antunes Powered by FreeBSD == * Windows: Where do you want to go tomorrow? * Linux: Where do you want to go today? * FreeBSD: Are you, guys, comming or what? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
