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
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 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 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 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. Desde já agradeço. Em 14 de março de 2011 14:23, kmkz bleh jsi...@gmail.com escreveu: 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.comescreveu: existe possibilidade de trocar a placa de rede
[FUG-BR] freebsd 8.2 - tuning de rede
Bom dia pessoal, Atualizei o meu servidor para FreeBSD 8.2 (estava usando antes o 7.3) e o problema com rede ainda persiste. Tenho um CMTS ligado diretamente em uma das placas do servidor e o ping para ele continua alto e variando muito. Peço desculpas desde já pelo tamanho do email, mas estou passando o máximo de informação possível, pois já não sei mais o que fazer... --- 10.20.0.2 ping statistics --- 413 packets transmitted, 413 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.148/2.119/28.606/3.833 ms A placa ligada no CMTS é uma Broadcom (bce0). bce0: flags=8843UP,BROADCAST, RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 1c:c1:de:08:de:90 inet 10.20.0.1 netmask 0xfffc broadcast 10.20.0.3 media: Ethernet 1000baseT full-duplex status: active bce0@pci0:11:0:0: class=0x02 card=0x7059103c chip=0x163914e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme II Gigabit Ethernet (BCM5709)' class = network subclass = ethernet Realizei ping para maquinas da rede interna e ta dando um tempo de 3ms, 4ms... E o estranho é que pegando a máquina da rede interna e pingando o servidor, tenho um tempo menor que 1ms. --- 192.168.0.10 ping statistics --- 71 packets transmitted, 71 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 3.121/4.284/21.869/2.188 ms Esta placa ligada na rede interna também é uma Broadcom (bce1), mesmo modelo da bce0, ligada em um switch cisco. bce1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 1c:c1:de:08:de:92 inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet 100baseTX full-duplex status: active FreeBSD gw-ija 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Mar 10 01:40:04 UTC 2011 root@:/usr/src/sys/i386/compile/SRVGW i386 Compilei o kernel com as seguintes opções: device pf device pflog device pfsync device carp options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=1000#limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options IPSTEALTH options IPFIREWALL_FORWARD options DUMMYNET options HZ=1000 options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options ZERO_COPY_SOCKETS As sysctls que alterei são somente essas (modificadas no momento do boot): kern.ipc.maxsockbuf=8388608 net.inet.tcp.rfc1323=1 net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 kern.ipc.somaxconn=1024 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.flowtable.enable=0 net.link.ether.inet.log_arp_wrong_iface=0 Mais algumas informações: CPU: Intel(R) Xeon(R) CPU E5504 @ 2.00GHz (2000.09-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 Possui 4GB de RAM e 8GB de swap. Desde já agradeço. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] freebsd 8.2 - tuning de rede
Oi Eduardo, depois do seu aperto aí e de ter solucionado o problema resolvi mudar tbem pra série 8... rs Ta ligado via cabo cross. Pelo meu cacti ontem bateu 201Mbps. Mas a média é em torno de 150Mbps, 140Mbps. Ainda não testei com switch giga, vou pedir pra colocar um entre ambos pra ver. Em 11 de março de 2011 09:45, Eduardo Schoedler eschoed...@viavale.com.brescreveu: Qual é o volume de tráfego? Usa cabo xover entre as 2 placas? Tentou colocar um switch giga, só para testar? -- Eduardo Schoedler Enviado via iPhone Em 11/03/2011, às 09:35, kmkz bleh jsi...@gmail.com escreveu: Bom dia pessoal, Atualizei o meu servidor para FreeBSD 8.2 (estava usando antes o 7.3) e o problema com rede ainda persiste. Tenho um CMTS ligado diretamente em uma das placas do servidor e o ping para ele continua alto e variando muito. Peço desculpas desde já pelo tamanho do email, mas estou passando o máximo de informação possível, pois já não sei mais o que fazer... --- 10.20.0.2 ping statistics --- 413 packets transmitted, 413 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.148/2.119/28.606/3.833 ms A placa ligada no CMTS é uma Broadcom (bce0). bce0: flags=8843UP,BROADCAST, RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 1c:c1:de:08:de:90 inet 10.20.0.1 netmask 0xfffc broadcast 10.20.0.3 media: Ethernet 1000baseT full-duplex status: active bce0@pci0:11:0:0: class=0x02 card=0x7059103c chip=0x163914e4 rev=0x20 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme II Gigabit Ethernet (BCM5709)' class = network subclass = ethernet Realizei ping para maquinas da rede interna e ta dando um tempo de 3ms, 4ms... E o estranho é que pegando a máquina da rede interna e pingando o servidor, tenho um tempo menor que 1ms. --- 192.168.0.10 ping statistics --- 71 packets transmitted, 71 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 3.121/4.284/21.869/2.188 ms Esta placa ligada na rede interna também é uma Broadcom (bce1), mesmo modelo da bce0, ligada em um switch cisco. bce1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c01bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether 1c:c1:de:08:de:92 inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet 100baseTX full-duplex status: active FreeBSD gw-ija 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Mar 10 01:40:04 UTC 2011 root@:/usr/src/sys/i386/compile/SRVGW i386 Compilei o kernel com as seguintes opções: device pf device pflog device pfsync device carp options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=1000#limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options IPSTEALTH options IPFIREWALL_FORWARD options DUMMYNET options HZ=1000 options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options ZERO_COPY_SOCKETS As sysctls que alterei são somente essas (modificadas no momento do boot): kern.ipc.maxsockbuf=8388608 net.inet.tcp.rfc1323=1 net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 kern.ipc.somaxconn=1024 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.flowtable.enable=0 net.link.ether.inet.log_arp_wrong_iface=0 Mais algumas informações: CPU: Intel(R) Xeon(R) CPU E5504 @ 2.00GHz (2000.09-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 Possui 4GB de RAM e 8GB de swap. Desde já agradeço. - 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
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] freebsd 8.2 - tuning de rede
Tenho ainda o seguinte, que creio poderá ajudar: gw# netstat -s tcp: 31195 packets sent 14892 data packets (3236025 bytes) 24 data packets (3417 bytes) retransmitted 5 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 15357 ack-only packets (3043 delayed) 0 URG only packets 0 window probe packets 4 window update packets 918 control packets 50425 packets received 13669 acks (for 3236988 bytes) 60 duplicate acks 0 acks for unsent data 28773 packets (21583175 bytes) received in-sequence 24 completely duplicate packets (6258 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 7 window update packets 755 packets received after close 2315 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 34 connection requests 859 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 891 connections established (including accepts) 888 connections closed (including 15 drops) 0 connections updated cached RTT on close 0 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 11681 segments updated rtt (of 12336 attempts) 23 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 1 keepalive timeout 1 keepalive probe sent 0 connections dropped by keepalive 571 correct ACK header predictions 27243 correct data packet header predictions 866 syncache entries added 12 retransmitted 6 dupsyn 0 dropped 859 completed 0 bucket overflow 0 cache overflow 5 reset 2 stale 0 aborted 0 badack 0 unreach 0 zone failures 866 cookies sent 0 cookies received 3 SACK recovery episodes 3 segment rexmits in SACK recovery episodes 152 byte rexmits in SACK recovery episodes 21 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 2028890 datagrams received 0 with incomplete header 0 with bad data length field 325 with bad checksum 567 with no checksum 120167 dropped due to no socket 12464 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 1895934 delivered 1897868 datagrams output 0 times multicast source filter matched ip: 356136822 total packets received 3 bad header checksums 0 with size smaller than minimum 3 with data size data length 0 with ip length max ip packet size 0 with header length data size 0 with data length header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 2110620 packets for this host 1529 packets for unknown/unsupported protocol 349766702 packets forwarded (0 packets fast forwarded) 60184 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 2018124 packets sent from this host 0 packets sent with fabricated ip header 11188 output packets dropped due to no bufs, etc. 37905 output packets discarded due to no route 603666 output datagrams fragmented 3182271 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 1354 datagrams with bad address in header icmp: 57497 calls to icmp_error 1383 errors not generated in response to an icmp message
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
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
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
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] Não usem FBSD-8x como router !!!
Eu também tive muita dor de cabeça com FreeBSD 8. Instamos o 8.0 em 3 operações, e em todas tivemos que fazer downgrade para FreeBSD 7, principalmente por causa do kernel panic entre outros, coisa que com a série 7 não acontece. Conforme email que mandei relatando meu problema, vou voltar com o 8.2 e ve se com ele vou ter mais sorte, apesar que não estou tão confiante assim. Poderia fazer o upgrade hoje, mas devido a dor de cabeça que tive - que não gosto nem de lembrar - e desses tipos de problema, não estou muito afim de ficar trabalhando no carnaval fazendo downgrade novamente :-P No meu caso as placas do servidor são Intel e Broadcom (emX, bgeX e bceX), com 4 sessões bgp fechada, sendo 3 full e 1 partial. Abraços. Em 2 de março de 2011 08:03, Renato Frederick ren...@frederick.eti.brescreveu: Eu tentei instalar o openbsd mais recente em um destes Dell que citei no email anterior, ao deparar com os problemas de igb. Acho que no total são 16 processadores que aparece pro FreeBSD, são 2 XEON que eles veem, daí da 8 processadores lógicos em cada socket. O openbsd ao colocar o kernel SMP dava panic. usando o kernel normal funcionava. Daí não dá para desperdiçar processador, deixei o open encostado mesmo. - 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: RES: tuning de rede - FreeBSD 7.3
Estou pensando em mudar para FreeBSD 8.2, porém, antes de fazer esta troca, verifiquei novamente algumas sysctls: net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.maxsegments: 16384 net.inet.tcp.reass.overflows: 0 Poderia esses valores estar prejudicando no desempenho? Em uma máquina com FreeBSD 7.1 tenho os seguintes valores: net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.maxsegments: 1600 net.inet.tcp.reass.overflows: 1359 As placas de rede são diferentes também. Abraços. Em 25 de fevereiro de 2011 17:52, kmkz bleh jsi...@gmail.com escreveu: Oi Edinilson, Segue: gw# sysctl kern.sched.name kern.sched.name: ULE Não troquei não. Em 25 de fevereiro de 2011 16:54, Edinilson - ATINET edinil...@atinet.com.br escreveu: Só de curiosidade, qual scheduler voce está utilizando? sysctl -a | grep kern.sched.name Já experimentou trocar? 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, February 25, 2011 1:27 PM Subject: Re: [FUG-BR] RES: RES: RES: tuning de rede - FreeBSD 7.3 Eduardo, Agora por exemplo, que o volume de tráfego está maior, tenho o seguinte: gw# uptime 1:25PM up 22:06, 1 user, load averages: 0.32, 0.21, 0.20 - 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: RES: RES: RES: tuning de rede - FreeBSD 7.3
Somente router... é o gateway da rede msm. Em 28 de fevereiro de 2011 16:18, Eduardo Schoedler eschoed...@viavale.com.br escreveu: Em 28/02/2011 16:08, kmkz bleh escreveu: Estou pensando em mudar para FreeBSD 8.2, porém, antes de fazer esta troca,verifiquei novamente algumas sysctls: ... Poderia esses valores estar prejudicando no desempenho? Você usa ele só como roteador ou servidor web (por ex) ? Caso seja somente router, ele não mantém sessões tcp, somente repassa pacotes (lê o cabeçalho). -- 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
Re: [FUG-BR] RES: RES: RES: tuning de rede - FreeBSD 7.3
Eduardo,
Agora por exemplo, que o volume de tráfego está maior, tenho o seguinte:
gw# uptime
1:25PM up 22:06, 1 user, load averages: 0.32, 0.21, 0.20
CPU: 0.2% user, 0.0% nice, 6.0% system, 24.6% interrupt, 69.2% idle
Mem: 299M Active, 641M Inact, 367M Wired, 60K Cache, 112M Buf, 2192M Free
Swap: 8192M Total, 8192M Free
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root1 171 ki31 0K 8K RUN 3 20.0H 86.77% idle:
cpu3
13 root1 171 ki31 0K 8K CPU11 19.4H 81.40% idle:
cpu1
14 root1 171 ki31 0K 8K RUN 0 18.6H 71.68% idle:
cpu0
12 root1 171 ki31 0K 8K CPU22 908:02 50.00% idle:
cpu2
29 root1 -68- 0K 8K WAIT2 282:14 39.45% irq257:
bce0
40 root1 -68- 0K 8K CPU22 235:20 30.66% irq265:
em3
28 root1 -68- 0K 8K - 0 78:17 9.38% em0 taskq
36 root1 -68- 0K 8K WAIT3 71:20 7.96% irq262:
em2
43 root1 -68- 0K 8K WAIT1 65:10 7.96% irq268:
bge0
44 root1 -68- 0K 8K WAIT2 63:04 7.08% irq269:
bge1
41 root1 -68- 0K 8K WAIT3 19:24 1.66% irq266:
em3
57 root1 8- 0K 8K pftm0 21:08 1.07% pfpurge
1665 root5 40 211M 171M kqread 1 3:53 0.49% named
37 root1 -68- 0K 8K WAIT0 7:08 0.20% irq263:
em2
39 root1 -68- 0K 8K - 0 11:35 0.00% em3 taskq
58 root1 -68- 0K 8K - 3 3:55 0.00% dummynet
35 root1 -68- 0K 8K - 0 3:53 0.00% em2 taskq
Eu vejo também na maior parte do tempo, em3 e bce0 estão usando cpu2. Ambas
são as interfaces com maior volume de tráfego. Já fixei a em3 por exemplo
para usar somente cpu1 e cpu0. Diminuiu o uso da cpu2 mas o problema
persistiu.
Em 24 de fevereiro de 2011 17:40, Eduardo Schoedler
eschoed...@viavale.com.br escreveu:
Dependendo da quantidade de tráfego que está passando nesse server, com
Firewall + roteamento + Interrupções (IRQ) devem estar matando sua cpu.
Qual o load dessa máquina ?
--
Eduardo Schoedler
-Mensagem original-
De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em
nome de kmkz bleh
Enviada em: quinta-feira, 24 de fevereiro de 2011 17:38
Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
Assunto: Re: [FUG-BR] RES: RES: tuning de rede - FreeBSD 7.3
Certo. Obrigado, vou dar uma lida sim.
Eu também utilizo pf na máquina onde faço uns route-to com as classes
inválidas. Logo no início eu tenho isso:
set limit { states 100, frags 10 }
set optimization normal
Será que isto pode estar atrapalhando?
-
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: RES: RES: tuning de rede - FreeBSD 7.3
Já fixei velocidade, deixei em modo automático... de qualquer maneira tenho perda. Testei também em outra placa, uma das Intel que o servidor tem e o resultado foi o mesmo. Em 25 de fevereiro de 2011 08:35, renato martins renato...@gmail.comescreveu: Pode até ser uma pergunta boba, mas você já tentou setar o modo de negociação da placa de rede para 100/half ou 100/full ? o driver pode ser tb noa teria como trocar essa placa de rede por uma intel dessas outras saidas que voce tem tantas ? Em 24 de fevereiro de 2011 23:33, Matheus Cucoloto matheuscucol...@gmail.com escreveu: Cara, faça um teste. Faça um route-map no bgp, aceitando APENAS a rota padrao anunciada pelos seus neighbors. Ou seja tire o full routing. Suspeito muito que voçe nao vai mais ter perda de pacote. Passa para nós o resultado. Em 24/02/2011 17:41, Eduardo Schoedler eschoed...@viavale.com.br escreveu: Dependendo da quantidade de tráfego que está passando nesse server, com Firewall + roteamento + Interrupções (IRQ) devem estar matando sua cpu. Qual o load dessa máquina ? -- Eduardo Schoedler -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freeb... Enviada em: quinta-feira, 24 de fevereiro de 2011 17:38 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunto: Re: [FUG-BR] RES: RES: tuning de rede - FreeBSD 7.3 Certo. Obrigado, vou dar uma lida sim. Eu também utilizo pf na máquina onde faço uns route... - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: ht... - 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 - 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: RES: RES: tuning de rede - FreeBSD 7.3
Na verdade me expressei mal, me desculpa... Eu usei cpuset para fixar o pid da irq265: em3 para outra cpu que não fosse a cpu2. Deixei um ping rodando agora e vi mensagem de no buffer space available. Pela primeira vez apareceu essa mensagem. 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.314 ms 64 bytes from 10.20.0.2: icmp_seq=1 ttl=255 time=0.226 ms 64 bytes from 10.20.0.2: icmp_seq=2 ttl=255 time=0.355 ms 64 bytes from 10.20.0.2: icmp_seq=3 ttl=255 time=9.130 ms ping: sendto: No buffer space available 64 bytes from 10.20.0.2: icmp_seq=5 ttl=255 time=16.008 ms 64 bytes from 10.20.0.2: icmp_seq=6 ttl=255 time=8.916 ms gw# vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES mbuf_packet: 256,0,3303,2969, 2756245720,0 mbuf: 256,0,4, 2694, 4021003569,0 mbuf_cluster: 2048,65536, 6273, 761, 1224704716,0 mbuf_jumbo_pagesize: 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, 10,0 Eu havia setado o kern.ipc.nmbclusters em 65536. Vou ter que aumentar este valor também. gw# uname -a FreeBSD gw 7.3-RELEASE FreeBSD 7.3-RELEASE #1: Wed Feb 23 14:54:05 BRT 2011 root@gw-ija:/usr/src/sys/i386/compile/SRVGW i386 Em 25 de fevereiro de 2011 13:36, Eduardo Schoedler eschoed...@viavale.com.br escreveu: Em 25/02/ 2011 13:27, kmkz bleh (quem?) escreveu: Já fixei a em3 por exemplo para usar somente cpu1 e cpu0. Diminuiu o uso da cpu2 mas o problema persistiu. Impossível, SMP IRQ-Affinity só apareceu a partir do 8.0 ! Pela thread, você diz estar usando o FBSD 7.3, a não ser que você esteja usando Linux... -- 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
Re: [FUG-BR] RES: RES: RES: tuning de rede - FreeBSD 7.3
Oi Edinilson, Segue: gw# sysctl kern.sched.name kern.sched.name: ULE Não troquei não. Em 25 de fevereiro de 2011 16:54, Edinilson - ATINET edinil...@atinet.com.br escreveu: Só de curiosidade, qual scheduler voce está utilizando? sysctl -a | grep kern.sched.name Já experimentou trocar? 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, February 25, 2011 1:27 PM Subject: Re: [FUG-BR] RES: RES: RES: tuning de rede - FreeBSD 7.3 Eduardo, Agora por exemplo, que o volume de tráfego está maior, tenho o seguinte: gw# uptime 1:25PM up 22:06, 1 user, load averages: 0.32, 0.21, 0.20 - 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: tuning de rede - FreeBSD 7.3
Pessoal, fiz um teste aqui pingando o ip que está na placa bce0, ou seja, pingando dentro do servidor, e apresentou perda de pacote: gw# ping 10.20.0.1 PING 10.20.0.1 (10.20.0.1): 56 data bytes 64 bytes from 10.20.0.1: icmp_seq=0 ttl=64 time=0.277 ms 64 bytes from 10.20.0.1: icmp_seq=1 ttl=64 time=0.032 ms 64 bytes from 10.20.0.1: icmp_seq=2 ttl=64 time=0.043 ms 64 bytes from 10.20.0.1: icmp_seq=3 ttl=64 time=0.066 ms 64 bytes from 10.20.0.1: icmp_seq=4 ttl=64 time=0.160 ms 64 bytes from 10.20.0.1: icmp_seq=5 ttl=64 time=0.090 ms 64 bytes from 10.20.0.1: icmp_seq=6 ttl=64 time=0.076 ms 64 bytes from 10.20.0.1: icmp_seq=7 ttl=64 time=0.032 ms 64 bytes from 10.20.0.1: icmp_seq=8 ttl=64 time=0.144 ms 64 bytes from 10.20.0.1: icmp_seq=27 ttl=64 time=8.071 ms 64 bytes from 10.20.0.1: icmp_seq=32 ttl=64 time=58.667 ms 64 bytes from 10.20.0.1: icmp_seq=35 ttl=64 time=21.965 ms 64 bytes from 10.20.0.1: icmp_seq=36 ttl=64 time=6.982 ms 64 bytes from 10.20.0.1: icmp_seq=44 ttl=64 time=12.355 ms 64 bytes from 10.20.0.1: icmp_seq=45 ttl=64 time=44.653 ms 64 bytes from 10.20.0.1: icmp_seq=57 ttl=64 time=36.951 ms 64 bytes from 10.20.0.1: icmp_seq=61 ttl=64 time=8.009 ms 64 bytes from 10.20.0.1: icmp_seq=71 ttl=64 time=7.947 ms 64 bytes from 10.20.0.1: icmp_seq=73 ttl=64 time=7.985 ms 64 bytes from 10.20.0.1: icmp_seq=76 ttl=64 time=76.018 ms ^C --- 10.20.0.1 ping statistics --- 82 packets transmitted, 20 packets received, 75.6% packet loss round-trip min/avg/max/stddev = 0.032/14.526/76.018/21.564 ms gw# ifconfig bce0 bce0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=1bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4 ether 1c:c1:de:08:de:90 inet 10.20.0.1 netmask 0xfffc broadcast 10.20.0.3 media: Ethernet 1000baseTX full-duplex status: active Em 23 de fevereiro de 2011 14:29, kmkz bleh jsi...@gmail.com escreveu: Oi Eduardo, Obrigado pela atenção. Já tentei usar FreeBSD série 8. Melhorou em alguns aspectos mas tive uma série de problemas. O bgp demorava fechar sessão, máquina travando constantemente com PANIC, na hora de rebootar tinha que tirar cabo de rede da placa senão voltava o PANIC, e na hora que ela estava no ar com tudo funcionando, após algumas horas o named simplesmente parava de responder. O processo continuava ativo e não morria em hipótese alguma (tentei kill, restart, stop, etc). Somente reiniciando o servidor causando mais transtorno ainda. Enfim, a experiência não foi boa. Quando coloquei o 7.3 pararam todos esses problemas, mas começou a apresentar esse desempenho ruim logo em seguida. É a única coisa que tenho a queixar. Verifiquei as variávies para o netisr e tenho as seguintes: gw# sysctl -a |grep net.isr net.isr.swi_count: -1834575374 net.isr.drop: 0 net.isr.queued: 752912 net.isr.deferred: 1770919304 net.isr.directed: 477816393 net.isr.count: -2046394068 net.isr.direct: 0 A respeito do flowtable não tem ele no 7.3. Inclusive quando usei a série 8, uma dos problemas que fazia a máquina travar depois que ativava o bgp era exatamente o flowtable. Até pensei que os problemas estavam resolvidos depois que desativei esta opção e vi o bgp rodando, mas, a alegria durou pouco. O kernel não foi compilado com ZERO_COPY_SOCKETS. Usei as opções abaixo para compilar: device pf device pflog device pfsync device carp options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=1000#limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options IPSTEALTH options IPFIREWALL_FORWARD options DUMMYNET options HZ=1000 options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ Desde já agradeço. Em 23 de fevereiro de 2011 12:30, Eduardo Schoedler eschoed...@viavale.com.br escreveu: A parte de network do Freebsd 8.2-PRERELEASE está bem melhor que a do 7.x. Tomei uma surra dos drivers bce e igb, mas agora está funcionando. As bce não são grande coisa, não aceitam polling e também a moderação de interrupção dela não é muito boa. As Intel são muito melhores. Você pode tentar mexer no netisr: # Some useful netisr tunables. See sysctl net.isr #net.isr.bindthreads=1 #net.isr.numthreads=4 #net.isr.defaultqlimit=4096 Tome cuidado com o flowtable, não sei se tem na versão 7.x: # Flowtable - flow caching mechanism net.inet.flowtable.enable=0 você compilou o kernel com a opção: options ZERO_COPY_SOCKETS Algumas urls para ajuda: http://serverfault.com/questions/64356/freebsd-performance-tuning-sysctls-lo ader-conf-kernel http://www.cymru.com/Documents/ip-stack-tuning.html http://lists.freebsd.org/pipermail/freebsd-performance/2009
Re: [FUG-BR] RES: RES: tuning de rede - FreeBSD 7.3
Eu ativei novamente a sysctl net.isr.direct e pingando do próprio gateway o ip na interface bce0, não tive mais perda de pacote. --- 10.20.0.1 ping statistics --- 100 packets transmitted, 100 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.029/0.994/31.557/4.767 ms Voltei a desativá-la e as perdas na interface bce0 acontecem: --- 10.20.0.1 ping statistics --- 15 packets transmitted, 7 packets received, 53.3% packet loss round-trip min/avg/max/stddev = 0.036/12.631/75.718/25.891 ms Quando desativada, o processo da placa bce0 fica baixo, mas sobe o uso de cpu para o processo abaixo: 44.87% swi1: net A máquina não bate 100% de cpu... não chega nem perto disso. É uma máquina muito boa: CPU: Intel(R) Xeon(R) CPU E5504 @ 2.00GHz (2000.08-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106a5 Stepping = 5 Cores per package: 8 Logical CPUs per core: 2 real memory = 3747803136 (3574 MB) avail memory = 3663925248 (3494 MB) ACPI APIC Table: HP ProLiant FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 Recompilei o kernel com a opção ZERO_COPY_SOCKETS mas não tive nenhuma melhora. A propósito, já testei ligando o CMTS em outra placa do servidor emX (chipset Intel) e o problema persistiu. Obrigado. Em 24 de fevereiro de 2011 15:10, Eduardo Schoedler eschoed...@viavale.com.br escreveu: Como está o consumo da cpu ??? Deixa rodando em um terminal: # systat -vmstat 1 E veja se bate em 100%. -- 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: tuning de rede - FreeBSD 7.3
Certo. Obrigado, vou dar uma lida sim.
Eu também utilizo pf na máquina onde faço uns route-to com as classes
inválidas. Logo no início eu tenho isso:
set limit { states 100, frags 10 }
set optimization normal
Será que isto pode estar atrapalhando?
Em 24 de fevereiro de 2011 16:33, Edinilson - ATINET
edinil...@atinet.com.br escreveu:
Há uma discussão, antiga, sobre o net.isr.direct que acho que valeria a
pena
dar uma lida:
http://lists.freebsd.org/pipermail/freebsd-performance/2005-October/001561.html
Ainda se discutia SE era melhor, ou não, deixar esta opcao ON (que acabou
ficando por padrao nas versoes 7.xx para cima).
obs: É interessante acompanhar toda a thread do topico.
Edinilson
-
ATINET-Professional Web Hosting
Tel Voz: (0xx11) 4412-0876
http://www.atinet.com.br
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] tuning de rede - FreeBSD 7.3
Bom dia pessoal. Tenho um servidor FreeBSD 7.3 com 8 placas de rede com chipset Intel e Broadcom. Este é o servidor gateway da minha rede no qual rodo: pf named (base) snmp openbgp Possuo três sessões BGP Full e uma Partial. O que acontece é que estou tendo uma performance muito ruim com relação a placa Broadcom. Possuo um CMTS ligado diretamente na placa sem switch no meio, e estou tendo perda de pacote até o CMTS. Já realizei troca de cabo e não resolveu. gw# ifconfig bce0 bce0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=1bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4 ether 1c:c1:de:08:de:90 inet 10.20.0.1 netmask 0xfffc broadcast 10.20.0.3 media: Ethernet 1000baseTX full-duplex status: active Verificando com 'top -S' o uso de interrupção na bce0 é bastante alto. O tráfego nesta placa passa dos 100Mbps na maior parte do tempo então consequentemente vai consumir mais cpu. Porém, através de uma sysctl abaixo consegui fazer com que esse uso fosse reduzido, mas continuo perdendo pacote até o CMTS: net.isr.direct=0 No momento o 'top -S' me mostra o seguinte: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 13 root1 171 ki31 0K 8K CPU11 45.3H 96.48% idle: cpu1 12 root1 171 ki31 0K 8K RUN 2 43.0H 90.77% idle: cpu2 14 root1 171 ki31 0K 8K RUN 0 40.0H 77.20% idle: cpu0 11 root1 171 ki31 0K 8K RUN 3 38.1H 73.00% idle: cpu3 15 root1 -44- 0K 8K WAIT3 19.8H 52.49% swi1: net 29 root1 -68- 0K 8K WAIT2 151:40 5.57% irq257: bce0 40 root1 -68- 0K 8K WAIT2 85:46 2.10% irq265: em3 Se eu ativo a sysctl acima, tenho o seguinte: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 11 root1 171 ki31 0K 8K CPU33 38.2H 92.87% idle: cpu3 13 root1 171 ki31 0K 8K CPU11 45.4H 84.38% idle: cpu1 14 root1 171 ki31 0K 8K RUN 0 40.1H 79.39% idle: cpu0 12 root1 171 ki31 0K 8K CPU22 43.1H 62.35% idle: cpu2 29 root1 -68- 0K 8K WAIT2 151:55 25.59% irq257: bce0 40 root1 -68- 0K 8K WAIT2 85:55 21.58% irq265: em3 Abaixo, resultado com netstat na interface: gw# netstat -I bce0 -w 1 input (bce0) output packets errs bytespackets errs bytes colls 15311 04469692 20459 0 17440474 0 15631 04589699 21200 0 18848188 0 15608 04497235 20683 0 17818101 0 15529 04446912 20156 0 17090265 0 14414 04071791 17597 0 14750674 0 14713 04270162 18578 0 15301508 0 15030 04332616 18052 0 15021321 0 13900 04053945 17033 0 13895997 0 14095 04051387 18936 0 16074572 0 15515 04518106 20720 0 17377395 0 15606 04468322 20386 0 17128122 0 15494 04611991 20409 0 17379323 0 15375 04584624 20574 0 17758892 0 15610 04435950 21340 0 18658094 0 15277 04573331 20444 0 17695037 0 Segue algumas sysctls no qual alterei os valores: kern.ipc.nmbclusters=65536 kern.ipc.nsfbufs=10240 kern.ipc.maxsockbuf=8388608 net.inet.tcp.rfc1323=1 net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 kern.ipc.somaxconn=1024 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.link.ether.inet.log_arp_wrong_iface=0 O ping começa com valor baixo depois sobe e o valor não cai denovo. Enquanto este ping está alto, eu abro uma nova shell e executo outro ping. Ele começa baixo por uns tempos, menor que 1ms, depois aumenta e iguala ao primeiro ping executado. 64 bytes from 10.20.0.2: icmp_seq=22 ttl=255 time=0.321 ms 64 bytes from 10.20.0.2: icmp_seq=23 ttl=255 time=0.291 ms 64 bytes from 10.20.0.2: icmp_seq=24 ttl=255 time=0.305 ms 64 bytes from 10.20.0.2: icmp_seq=25 ttl=255 time=0.304 ms 64 bytes from 10.20.0.2: icmp_seq=26 ttl=255 time=0.197 ms 64 bytes from 10.20.0.2: icmp_seq=27 ttl=255 time=0.361 ms 64 bytes from 10.20.0.2: icmp_seq=28 ttl=255 time=0.277 ms 64 bytes from 10.20.0.2: icmp_seq=29 ttl=255 time=0.233 ms 64 bytes from 10.20.0.2: icmp_seq=30 ttl=255 time=10.524 ms 64 bytes from 10.20.0.2: icmp_seq=31 ttl=255 time=23.673 ms 64 bytes from 10.20.0.2: icmp_seq=32 ttl=255 time=44.541 ms 64 bytes from 10.20.0.2: icmp_seq=33 ttl=255 time=10.661 ms 64 bytes from 10.20.0.2: icmp_seq=34 ttl=255 time=6.178 ms 64 bytes from 10.20.0.2: icmp_seq=35 ttl=255 time=7.265 ms 64 bytes from
Re: [FUG-BR] RES: tuning de rede - FreeBSD 7.3
Oi Eduardo, Obrigado pela atenção. Já tentei usar FreeBSD série 8. Melhorou em alguns aspectos mas tive uma série de problemas. O bgp demorava fechar sessão, máquina travando constantemente com PANIC, na hora de rebootar tinha que tirar cabo de rede da placa senão voltava o PANIC, e na hora que ela estava no ar com tudo funcionando, após algumas horas o named simplesmente parava de responder. O processo continuava ativo e não morria em hipótese alguma (tentei kill, restart, stop, etc). Somente reiniciando o servidor causando mais transtorno ainda. Enfim, a experiência não foi boa. Quando coloquei o 7.3 pararam todos esses problemas, mas começou a apresentar esse desempenho ruim logo em seguida. É a única coisa que tenho a queixar. Verifiquei as variávies para o netisr e tenho as seguintes: gw# sysctl -a |grep net.isr net.isr.swi_count: -1834575374 net.isr.drop: 0 net.isr.queued: 752912 net.isr.deferred: 1770919304 net.isr.directed: 477816393 net.isr.count: -2046394068 net.isr.direct: 0 A respeito do flowtable não tem ele no 7.3. Inclusive quando usei a série 8, uma dos problemas que fazia a máquina travar depois que ativava o bgp era exatamente o flowtable. Até pensei que os problemas estavam resolvidos depois que desativei esta opção e vi o bgp rodando, mas, a alegria durou pouco. O kernel não foi compilado com ZERO_COPY_SOCKETS. Usei as opções abaixo para compilar: device pf device pflog device pfsync device carp options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=1000#limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options IPSTEALTH options IPFIREWALL_FORWARD options DUMMYNET options HZ=1000 options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ Desde já agradeço. Em 23 de fevereiro de 2011 12:30, Eduardo Schoedler eschoed...@viavale.com.br escreveu: A parte de network do Freebsd 8.2-PRERELEASE está bem melhor que a do 7.x. Tomei uma surra dos drivers bce e igb, mas agora está funcionando. As bce não são grande coisa, não aceitam polling e também a moderação de interrupção dela não é muito boa. As Intel são muito melhores. Você pode tentar mexer no netisr: # Some useful netisr tunables. See sysctl net.isr #net.isr.bindthreads=1 #net.isr.numthreads=4 #net.isr.defaultqlimit=4096 Tome cuidado com o flowtable, não sei se tem na versão 7.x: # Flowtable - flow caching mechanism net.inet.flowtable.enable=0 você compilou o kernel com a opção: options ZERO_COPY_SOCKETS Algumas urls para ajuda: http://serverfault.com/questions/64356/freebsd-performance-tuning-sysctls-lo ader-conf-kernel http://www.cymru.com/Documents/ip-stack-tuning.html http://lists.freebsd.org/pipermail/freebsd-performance/2009-December/003909. html http://tunggul.staff.uns.ac.id/2008/08/07/tuning-freebsd-router/ http://www.fug.com.br/historico/html/freebsd/2010-12/msg00250.html http://unix.derkeiler.com/Mailing-Lists/FreeBSD/performance/2005-01/0061.htm l Rolou também um thread minha aqui no FUG sobre performance de rede... mas tudo em 8.x. Abs. -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
