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

["Tiago A. Peçanha"]

Essa realmente é o planejamento para o novo cenário. Mas estamos 
precisando dar um ajuste para estender a vida útil um pouco mais até que 
o novo cenário esteja resolvido.

Em 21/11/2012 17:43, Lucas Willian Bocchi escreveu:
> Como muito bem respondeu o Henrique, apenas complemento que borda é borda,
> firewall é firewall. Não é muito bom misturar as estações.
> Se puder dividir o trabalho da máquina, melhor.
>
>
> Em 21 de novembro de 2012 17:31, Henrique de Moraes Holschuh<
> henrique.holschuh at ima.sp.gov.br>  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.
>>
>> --
>> Henrique de Moraes Holschuh<hmh at ima.sp.gov.br>
>> IM@ - Informática de Municípios Associados
>> Engenharia de Telecomunicações
>> TEL +55-19-3755-6555/CEL +55-19-9293-9464
>>
>> Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
>> e do custo que você pode evitar.
>>
>>
>> __
>> masoch-l list
>> https://eng.registro.br/**mailman/listinfo/masoch-l<https://eng.registro.br/mailman/listinfo/masoch-l>
>>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l