[GTER] ksoftirqd 100%
Juliano Primavesi | KingHost
juliano at kinghost.com.br
Fri Aug 2 20:04:41 -03 2013
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
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
More information about the gter
mailing list