Como posso saber qual IRQ é responsável pelo alto uso da CPU

Mudei um servidor de uma placa principal para outra devido a uma falha no controlador de disco.

Desde então, notei que constantemente 25% de um dos núcleos sempre vai para o IRQ, mas não consegui saber qual é o IRQ responsável por isso.

O kernel é um Linux 2.6.18-194.3.1.el5 (CentOS). mpstat -P ALLmostra:

18:20:33     CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
18:20:33     all    0,23    0,00    0,08    0,11    6,41    0,02    0,00   93,16   2149,29
18:20:33       0    0,25    0,00    0,12    0,07    0,01    0,05    0,00   99,49    127,08
18:20:33       1    0,14    0,00    0,03    0,04    0,00    0,00    0,00   99,78      0,00
18:20:33       2    0,23    0,00    0,02    0,03    0,00    0,00    0,00   99,72      0,02
18:20:33       3    0,28    0,00    0,15    0,28   25,63    0,03    0,00   73,64   2022,19

Este é o / proc / interrompe

cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       
  0:        245          0          0    7134094    IO-APIC-edge  timer
  8:          0          0         49          0    IO-APIC-edge  rtc
  9:          0          0          0          0   IO-APIC-level  acpi
 66:         67          0          0          0   IO-APIC-level  ehci_hcd:usb2
 74:     902214          0          0          0         PCI-MSI  eth0
169:          0          0         79          0   IO-APIC-level  ehci_hcd:usb1
177:          0          0          0    7170885   IO-APIC-level  ata_piix, b4xxp
185:          0          0          0      59375   IO-APIC-level  ata_piix
NMI:          0          0          0          0 
LOC:    7104234    7104239    7104243    7104218 
ERR:          0
MIS:          0

Como posso identificar qual IRQ está causando o alto uso da CPU?

Editar:

Saída de dmesg | grep -i b4xxp

wcb4xxp 0000:30:00.0: probe called for b4xx...
wcb4xxp 0000:30:00.0: Identified Wildcard B410P (controller rev 1) at 00012000, IRQ 177
wcb4xxp 0000:30:00.0: VPM 0/1 init: chip ver 33
wcb4xxp 0000:30:00.0: VPM 1/1 init: chip ver 33
wcb4xxp 0000:30:00.0: Hardware echo cancellation enabled.
wcb4xxp 0000:30:00.0: Port 1: TE mode
wcb4xxp 0000:30:00.0: Port 2: TE mode
wcb4xxp 0000:30:00.0: Port 3: TE mode
wcb4xxp 0000:30:00.0: Port 4: TE mode
wcb4xxp 0000:30:00.0: Did not do the highestorder stuff
wcb4xxp 0000:30:00.0: new card sync source: port 3

Bem, como você está perguntando especificamente como saber em qual IRQ é responsável pelo número mpstat, você pode assumir que não é o LOC (local interrupt timer), pois esses números são razoavelmente iguais e ainda mpstatmostram alguns desses cpus em 0% irq.

Isso deixa o IRQ 0, que é o timer do sistema e sobre o qual você não pode fazer nada, e o IRQ 177, que está vinculado ao seu driver b4xxp.

Meu palpite é que o IRQ 177 seria seu culpado.

Se isso está causando um problema e você gostaria de mudar o comportamento, veja:

1. desativando o software que usa esse cartão e veja se as interrupções diminuem.

2. remover esse cartão do sistema e descarregar o driver e verificar se há melhorias.

3. mova esse cartão para outro slot e veja se isso ajuda.

4. verifique se há drivers ou patches atualizados para o software.

Se não for um problema e você estiver curioso, continue. :)

watch -n1 -d cat /proc/interrupts

BP410P é uma placa ISDN com 4 linhas BRI, se todas as quatro linhas estiverem conectadas, você deverá receber quatro pacotes de sincronização de cada vez e quando as chamadas estiverem sendo feitas, você poderá ter 8 canais de voz ativos em todos os pacotes de envio, etc.

Se você obtiver uma contagem alta de IRQ sem fazer chamadas, isso pode ser um sintoma de duas coisas ruins:

1. Há um problema de sincronização com o operador, você também deve ter uma qualidade de voz ruim.
2. As linhas de IRQ estão em conflito; neste caso, o seu ata_piix(ide / sata) está usando a mesma linha da placa BP410P, os drivers podem não gostar muito, nesse caso, a resposta anterior sugeriu tentar mudar a placa para outro slot .

Para depurar, você também pode tentar remover os cabos BRI e ver se isso faz diferença.

Eu me encontrei nessa situação há algum tempo e escrevi uma pequena irqtopferramenta para monitorar facilmente o que está acontecendo. É basicamente a mesma coisa que fazer um watch -n 1 cat /proc/interrupts, com uma saída melhor.

Código fonte disponível aqui: https://gitlab.com/elboulangero/irqtop