Come posso sapere quale IRQ è responsabile dell'utilizzo elevato della CPU

Ho spostato un server da una scheda madre a un'altra a causa di un errore del controller del disco.

Da allora ho notato che costantemente il 25% di uno dei core va sempre all'IRQ, tuttavia non sono riuscito a sapere qual è l'IRQ responsabile di ciò.

Il kernel è un Linux 2.6.18-194.3.1.el5 (CentOS). mpstat -P ALLSpettacoli:

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

Questo è / proc / interrupt

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

Come posso identificare quale IRQ sta causando un elevato utilizzo della CPU?

Modificare:

Uscita da 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

Bene, poiché in particolare stai chiedendo come sapere quale IRQ è responsabile del numero in mpstat, puoi presumere che non sia il timer di interruzione locale (LOC), dal momento che quei numeri sono abbastanza uguali, e tuttavia mpstatmostra alcuni di quei cpus allo 0% IRQ.

Ciò lascia IRQ 0, che è il timer di sistema e di cui non puoi fare nulla, e IRQ 177, che è legato al tuo driver b4xxp.

La mia ipotesi è che IRQ 177 sarebbe il tuo colpevole.

Se questo sta causando un problema e desideri cambiare il comportamento che vedi, prova:

1. disabilitando il software che utilizza quella scheda e vedere se gli interrupt diminuiscono.

2. rimuovendo quella scheda dal sistema e scaricando il driver, e vedere se c'è miglioramento.

3. sposta quella carta in un altro slot e vedi se aiuta.

4. verifica la presenza di driver o patch aggiornati per il software.

Se non è un problema e tu eri solo curioso, allora vai avanti. :)

watch -n1 -d cat /proc/interrupts

BP410P è una scheda ISDN con 4 linee BRI, se tutte e quattro le linee sono collegate dovresti ricevere quattro pacchetti di sincronizzazione alla volta e quando vengono effettuate le chiamate puoi avere 8 canali di voci attivi tutti i pacchetti di invio, ecc.

Se ricevi un conteggio IRQ elevato senza effettuare chiamate, questo potrebbe essere un sintomo di 2 cose cattive:

1. C'è un problema di sincronizzazione con l'operatore, dovresti anche avere una cattiva qualità della voce.
2. Le linee IRQ sono in conflitto, in questo caso il tuo ata_piix(ide / sata) utilizza la stessa linea con la scheda BP410P, i driver potrebbero non apprezzare molto, in questo caso la risposta precedente suggerisce di provare a cambiare la scheda in un altro slot .

Per eseguire il debug puoi anche provare a rimuovere i cavi BRI e vedere se fa la differenza.

Mi sono trovato in una situazione del genere qualche tempo fa e ho scritto un piccolo irqtopstrumento per monitorare facilmente cosa sta succedendo. È praticamente la stessa cosa di fare un watch -n 1 cat /proc/interrupts, con un output migliore.

Codice sorgente disponibile qui: https://gitlab.com/elboulangero/irqtop