[MASOCH-L] Alto uso de software interrupts (%si + irqs/seq) ksoftirqd

["Tiago A. Peçanha"]

Henrique,
Seguindo sua idéia do conntrack, como eu desabilitaria o retorno das 
conexões de serem rastreadas pelo conntrack? Ex:
iptables -t mangle -A PREROUTING -d x.x.x.x/24 -i eth0 -p tcp --sport 80 
-j MARK --set-mark 11
iptables -t mangle -A PREROUTING -d x.x.x.y/24 -i eth0 -p tcp --sport 80 
-j MARK --set-mark 11

Sendo 11, tabela:
rt_tables:
11      cache1

ip rule add fwmark 11 table cache1
ip route add default via 177.x.x.x dev eth1 table cache1

Ou a natureza dessas regras não permite isso?


Em 21/11/2012 17:31, Henrique de Moraes Holschuh escreveu:
> On 21-11-2012 17:21, Tiago A. Pecanha wrote:
>> Boa tarde a todos,
>> Estou com uma situação aqui bem estranha. De um tempo para cá um 
>> servidor DELL (16GB RAM) com quagga + iptables que está funcionando 
>> como borda começou a apresentar uma alta utilização de cpu pelo  
>> processo: ksoftirqd e isso gera aumento de latência e lentidão na rede.
>>
>> Investigando, percebi que quando desativo as regras de prerouting 
>> (mangle) o problema não ocorre, ou se ocorre, é raro.
>
> ksoftirqd alto implica que o kernel está tendo que bicar o 
> processamento de pacote por excessiva latência.
>
>> Segue detalhes do pert top:
>>    PerfTop:   53248 irqs/sec  kernel:99.1% [100000 cycles],  (all, 4 
>> CPUs)
>> ------------------------------------------------------------------------------ 
>>
>>
>>               samples    pcnt   kernel function
>>               _______   _____   _______________
>>
>>              69219.00 - 35.2% : __nf_conntrack_find    [nf_conntrack]
>>              35383.00 - 18.0% : nf_conntrack_tuple_taken    
>> [nf_conntrack]
>>              12884.00 -  6.6% : ipt_do_table    [ip_tables]
>>              11483.00 -  5.8% : __nf_conntrack_confirm    [nf_conntrack]
>
> Precisa mesmo de conntrack na borda?  Aqui marcamos tudo como 
> NO_TRACK, exceto o que for direcionado à caixa propriamente dita.  
> Melhor ainda é retirar do kernel o suporte (e tire o ebtables também).
>
>> NMI:  107596285  107592380  107599814  107591919   Non-maskable 
>> interrupts
>
> Muita NMI. Descubra porquê, e resolva. Não é normal, nem é boa ideia. 
> Se for o NMI watchdog, você realmente precisa dele com uma frequência 
> tão alta assim?
>
> Tente utilizar o irqbalance para ver se o comportamento geral das 
> interrupções melhora um pouco, você está com tudo em round-robin, o 
> que nem sempre é bom devido a efeitos de cache.
>
>> PMI:  107596280  107592379  107599813  107591912   Performance 
>> monitoring interrupts
>> PND:  107569857  107566488  107574071  107566157   Performance 
>> pending work
> Pare de rodar perf se não estiver precisando dele. Isso não sai de 
> graça, perturba o cache e gasta tempo de CPU.
>
> De resto, faça o tunning da NAPI via ethtool e parâmetros dos drivers 
> da placa de rede, para ter certeza que não está entrando em modo de 
> polling por excesso de interrupções.
>