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=8843 metric 0 mtu 1500 options=1bb ether 1c:c1:de:08:de:90 inet 10.20.0.1 netmask 0xfffc broadcast 10.20.0.3 media: Ethernet 1000baseTX status: active Em 23 de fevereiro de 2011 14:29, kmkz bleh 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-December/
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
[FUG-BR] RES: tuning de rede - FreeBSD 7.3
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 > -Mensagem original- > De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em > nome de kmkz bleh > Enviada em: quarta-feira, 23 de fevereiro de 2011 12:19 > Para: freebsd@fug.com.br > Assunto: [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=8843 metric 0 mtu > 1500 > > options=1bb ,TSO4> > ether 1c:c1:de:08:de:90 > inet 10.20.0.1 netmask 0xfffc broadcast 10.20.0.3 > media: Ethernet 1000baseTX > 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 1865
