[GTER] ksoftirqd 100%

[Lucas Willian Bocchi]

Tente recompilar o kernel com opcoes como HPET desabilitado e o resolution
timer para 1000hz e veja se melhora.
Ja no proprio changelog do kernel (se nao me engano da serie 3.5 para
frente) houve mudancas na forma do kernel tratar o pppoe. Veja se nao ha
uma melhora.


Em 3 de agosto de 2013 00:50, 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>
>