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

["Tiago A. Peçanha"]

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).

Desculpe a ignorância, nossas regras de fw são basicamente:
1) Algumas regras INPUT para acesso a máquina remotamente.
2) Algumas regras FORWARD para permitir acesso a partes/serviços 
internos da rede (DNS, clientes de ip fixo, etc...)
3) E as regras de mangle para redirecionar o tráfego externo destinado a 
porta 80 para uma tabela de roteamento que redireciona para os caches 
squid.

Quando eu examino "cat /proc/net/ip_conntrack" vejo muitas conexões 
listando ali. Mas não saberia dizer se isso significa que é requisito o 
conntrack.
>
>> 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?
>
Qual a melhor forma de fazer o troubleshooting? Ou qual a melhor 
abordagem para o watchdog? Temos o watchdog por default rodando sim. 
Entendo que poderia estar ocorrendo algum problema de hardware que 
esteja fazendo crescer este tipo de interrupção? Além é claro do próprio 
watchdog?

> 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.
>
O irqbalance está executando.

>> 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.
>
O perf só executo nos momentos de problema para ter noção dos irqs.

> 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.
>

Seguem alguns dados das placas:

ethtool -c eth0/1/2/3
Coalesce parameters for eth0:
Adaptive RX: off  TX: off
stats-block-usecs: 999936
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 18
rx-frames: 12
rx-usecs-irq: 18
rx-frames-irq: 2

tx-usecs: 80
tx-frames: 20
tx-usecs-irq: 18
tx-frames-irq: 2

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

Alguma referência de como fazer o tweak disso corretamente?