[GTER] ksoftirqd 100%

[Marcelo Gondim]

Em 15/08/13 15:49, Fabiann Freitas escreveu:
> Prezado,
>
> Conseguiu alguma solucao definitiva pra isso ?!
Oi Fabiann,

Pelo jeito é um problema com o driver ou o modelo da interface Intel que 
estou usando. De qualquer forma estou abandonando o PPPoE e partindo 
para Hotspot que usa DHCP + Login + Senha + Mac Address. Fica bem mais 
leve a rede e o servidor não precisa de tanto processamento quanto um 
concentrador PPPoE.

>
>
> Em Fri, 02 Aug 2013 19:10:48 -0300, 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
>
>