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

Question

Mudei um servidor de uma placa-mãe para outra devido a uma falha no controlador de disco.

Desde então, tenho notado que constantemente um 25% de um dos núcleos vai sempre para o IRQ, no entanto eu 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 ALL mostra:

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

Esta é a / proc / interrupts

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

    

Answer 1

Bem, como você está perguntando especificamente como saber qual IRQ é responsável pelo número em mpstat , você pode assumir que não é o cronômetro de interrupção local (LOC), pois esses números são praticamente iguais e, ainda assim, mpstat mostra alguns desses cpus a 0% irq.

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

Meu palpite é que o IRQ 177 seria o seu culpado.

Se isso estiver causando um problema e você quiser alterar o comportamento exibido, tente:

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

2. removendo essa placa do sistema e descarregando o driver, e veja se há melhorias.

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

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

Se não é um problema, e você estava apenas curioso, então continue. :)

    

Answer 2

BP410P é uma placa ISDN com 4 linhas BRI, se todas as quatro linhas estiverem conectadas, você deve receber quatro pacotes de sincronismo por vez e quando as chamadas estiverem sendo feitas, você pode ter 8 vozes ativas em todos os pacotes de envio, etc.

Se você obtiver uma contagem alta de IRQs sem fazer nenhuma chamada, 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. Linhas de IRQ são conflitantes, neste caso o seu ata_piix (ide / sata) está usando a mesma linha que tem o cartão BP410P, os drivers podem não gostar muito disso, nesse caso tem a resposta anterior sugerida tente e mude o cartão para outro slot.

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

    

Answer 3

watch -n1 -d cat /proc/interrupts

    

Answer 4

Eu encontrei-me em tal situação há algum tempo atrás, e eu escrevi uma pequena ferramenta irqtop para monitorar facilmente o que está acontecendo. É basicamente a mesma coisa que fazer um watch -n 1 cat /proc/interrupts , com uma saída mais agradável.

Código-fonte disponível aqui: link

Espero que isso ajude:)