[GTER] ksoftirqd 100%
Marcelo Gondim
gondim at intnet.com.br
Sun Aug 4 02:30:38 -03 2013
Em 03/08/13 21:23, Lucas Willian Bocchi escreveu:
> Resolveu mesmo? Nao houve aumento de latencia nos end users?
Não tem aquele ditado que diz "alegria de pobre dura pouco" ? Pois é
estava tudo indo bem mas fiz outras coisas como coloquei o kernel 3.9 do
backport do Debian e embora o ksoftirqd esteja subindo, pelo gráfico que
tenho gerado de consumo parece estar tudo normal e os clientes não estão
reclamando.
Mesmo assim resolvi fazer outra coisa baixei o kernel 3.10.4 e estou
recompilando com a sua ideia e removendo outras coisas desnecessárias. O
que o Rubens disse tem tudo à ver e pode ser o grande motivo do problema
que é justamente os pacotes frame de pppoe discovery e pppoe session
batendo na interface e levando-se em conta a quantidade de clientes
conectados e o tráfego a coisa vai piorando. Com o kernel 3.9 o
ksoftirqd subiu mas mantiveram-se estáveis as conexões. Vou ver com o
3.10.4 recompilado.
> Em 03/08/2013 07:17, "Marcelo Gondim" <gondim at intnet.com.br> escreveu:
>
>> Em 02/08/13 21:54, Lucas Willian Bocchi escreveu:
>>
>>> Qual a versao do kernel?
>>>
>> Linux pppoeserver 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux
>>
>> Em 02/08/2013 19:23, "Marcelo Gondim" <gondim at intnet.com.br> escreveu:
>>> Pessoal,
>>>> Faz muito tempo que não uso Linux em qualquer solução de roteamento com
>>>> tráfego alto. Tenho usado FreeBSD mas hoje voltei à fazer testes com o
>>>> Linux como concentrador PPPoE e quando o tráfego chega em 80Mbps lá vem a
>>>> porcaria do ksoftirqd consumindo CPU. Sei que isso está relacionado com a
>>>> alta requisição de interrupção no sistema mas pelo amor de Deus com
>>>> 80Mbps?
>>>> A máquina é um Dual Quad Xeon de 3.0 Ghz com 8Gb de ram e uma Intel
>>>> Server
>>>> Dual Port Gigabit.
>>>>
>>>> Anulei os conntracks usando:
>>>>
>>>> iptables -A OUTPUT -t raw -j NOTRACK
>>>> iptables -A PREROUTING -t raw -j NOTRACK
>>>>
>>>> Com isso não gero nenhuma conntrack no sistema.
>>>> Fiz o cpu affinity distribuindo as irqs das interfaces de rede nas cpus.
>>>>
>>>> Alguns sysctls que setei:
>>>>
>>>> echo 65535 > /proc/sys/net/ipv4/neigh/****default/gc_thresh1
>>>> echo 65535 > /proc/sys/net/ipv4/neigh/****default/gc_thresh2
>>>> echo 65535 > /proc/sys/net/ipv4/neigh/****default/gc_thresh3
>>>> echo 0 > /proc/sys/net/ipv4/route/gc_****min_interval
>>>> echo 524288 > /proc/sys/net/ipv4/route/max_****size
>>>> echo 3276822 > /proc/sys/net/nf_conntrack_max
>>>> echo 28800 > /proc/sys/net/ipv4/netfilter/***
>>>> *ip_conntrack_tcp_timeout_**
>>>> established
>>>> echo 60 > /proc/sys/net/ipv4/netfilter/****ip_conntrack_tcp_timeout_syn_
>>>> ****
>>>> sent
>>>> echo 30 > /proc/sys/net/ipv4/netfilter/****ip_conntrack_tcp_timeout_syn_
>>>> ****
>>>> recv
>>>> echo 60 > /proc/sys/net/ipv4/netfilter/****ip_conntrack_tcp_timeout_fin_
>>>> ****
>>>> wait
>>>> echo 30 > /proc/sys/net/ipv4/netfilter/****ip_conntrack_tcp_timeout_**
>>>> close_wait
>>>> echo 15 > /proc/sys/net/ipv4/netfilter/****ip_conntrack_tcp_timeout_**
>>>> last_**
>>>> ack
>>>> echo 60 > /proc/sys/net/ipv4/netfilter/****ip_conntrack_tcp_timeout_**
>>>> time_**
>>>> wait
>>>> echo 5 > /proc/sys/net/ipv4/netfilter/****ip_conntrack_tcp_timeout_**
>>>> close
>>>> echo 15 > /proc/sys/net/ipv4/netfilter/****ip_conntrack_udp_timeout
>>>> echo 90 > /proc/sys/net/ipv4/netfilter/****ip_conntrack_udp_timeout_****
>>>> stream
>>>> echo 15 > /proc/sys/net/ipv4/netfilter/****ip_conntrack_icmp_timeout
>>>> echo 300 > /proc/sys/net/ipv4/netfilter/****ip_conntrack_generic_timeout
>>>>
>>>> Mas mesmo com tudo isso ainda acontece o problema e o pior é que com
>>>> exatamente esse mesmo hardware eu seguro um tráfego de 1.2Gbps no FreeBSD
>>>> com lacp.
>>>>
>>>> Vi em alguns lugares que uma solução seria setar esse cara no boot pra 1:
>>>> /sys/module/intel_idle/****parameters/max_cstate
>>>>
>>>> Mas vi que isso não seria a solução correta.
>>>>
>>>> Alguém conseguiu descobrir como resolver esse problema definitivamente?
>>>>
>>>> []'s
>>>> Gondim
>>>>
>>>> --
>>>> gter list https://eng.registro.br/****mailman/listinfo/gter<https://eng.registro.br/**mailman/listinfo/gter>
>>>> <https://**eng.registro.br/mailman/**listinfo/gter<https://eng.registro.br/mailman/listinfo/gter>
>>>> --
>>> gter list https://eng.registro.br/**mailman/listinfo/gter<https://eng.registro.br/mailman/listinfo/gter>
>>>
>>>
>> --
>> gter list https://eng.registro.br/**mailman/listinfo/gter<https://eng.registro.br/mailman/listinfo/gter>
>>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
More information about the gter
mailing list