[GTER] ksoftirqd 100%

[Marcelo Gondim]

Em 02/08/13 20:04, Juliano Primavesi | KingHost escreveu:
>
> A placa deve ser muito ruim ou a porta esta bixada.
>
> Usa irq_affinity ou irqbalance.
>
> Deve estar TUDO na CPU0
>
> Verifica isso com cat /proc/interrupts
>
> Juliano
>
Antes fosse isso Juliano. Como eu disse eu fiz cpu affinity e como a 
interface [1] tem MSI-X joguei cada interrupção em uma CPU diferente. A 
motherboard é uma Intel S5500BC [2] com 2 processadores Xeon espetados 
nela e 8Gb de ram sendo 4Gb por processador.


[1] 
http://ark.intel.com/products/50397/Intel-Gigabit-ET-Dual-Port-Server-Adapter
[2] 
http://www.intel.com/products/server/motherboards/s5500bc/s5500bc-specifications.htm

Vou até alterar um dado interessante: esse mesmo hardware que estou 
fazendo os testes era um router FreeBSD que segurava um tráfego de 
1.2Gbps e que troquei recentemente.

> Em 02/08/2013 19:10, Marcelo Gondim 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
>
> -- 
> gter list    https://eng.registro.br/mailman/listinfo/gter
>