[FUG-BR] RES: freebsd 8.2 - tuning de rede
kmkz bleh
jsibsd em gmail.com
Terça Março 15 00:28:23 BRT 2011
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: em0 21311 19
irq258: em0 2 0
irq259: em1 665 0
irq260: bce0 11311742 10503
irq261: bce1 59430 55
irq262: em2 1954193 1814
irq263: em2 2460842 2284
irq264: em2 1 0
irq265: em3 6807389 6320
irq266: em3 6870682 6379
irq267: em3 14 0
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 <jsibsd em 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.listas em 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 <jsibsd em 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
>> > <edinilson em atinet.com.br>escreveu:
>> >
>> >> 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" <jsibsd em gmail.com>
>> >> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>> >> <freebsd em 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
>>
>
>
Mais detalhes sobre a lista de discussão freebsd