Bagaimana saya bisa tahu IRQ mana yang bertanggung jawab atas penggunaan CPU yang tinggi

Saya telah memindahkan server dari satu mainboard ke yang lain karena kegagalan pengontrol disk.

Sejak itu saya telah memperhatikan bahwa terus-menerus 25% dari salah satu inti selalu menjadi IRQ namun saya belum berhasil mengetahui IRQ mana yang bertanggung jawab untuk itu.

Kernel adalah Linux 2.6.18-194.3.1.el5 (CentOS). mpstat -P ALLmenunjukkan:

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

Ini adalah / proc / interupsi

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

Bagaimana saya bisa mengidentifikasi IRQ mana yang menyebabkan penggunaan CPU tinggi?

Edit:

Output dari 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

Nah, karena Anda secara khusus bertanya bagaimana mengetahui IRQ mana yang bertanggung jawab untuk nomor dalam mpstat, Anda dapat menganggap itu bukan interrupt timer lokal (LOC), karena angka-angka itu cukup sama, namun mpstatmenunjukkan beberapa CPU tersebut pada 0% irq.

Itu meninggalkan IRQ 0, yang merupakan pengatur waktu sistem, dan yang tidak bisa Anda lakukan, dan IRQ 177, yang terkait dengan driver b4xxp Anda.

Dugaan saya adalah bahwa IRQ 177 akan menjadi penyebab Anda.

Jika ini menyebabkan masalah, dan Anda ingin mengubah perilaku yang Anda lihat, cobalah:

1. menonaktifkan perangkat lunak yang menggunakan kartu itu, dan melihat apakah interupsi berkurang.

2. lepaskan kartu itu dari sistem, dan bongkar driver, dan lihat apakah ada peningkatan.

3. pindahkan kartu itu ke slot lain dan lihat apakah itu membantu.

4. periksa driver atau tambalan yang diperbarui untuk perangkat lunak.

Jika tidak masalah, dan Anda hanya ingin tahu, lanjutkan. :)

watch -n1 -d cat /proc/interrupts

BP410P adalah kartu ISDN dengan 4 Garis BRI, jika keempat saluran terhubung, Anda harus mendapatkan empat paket sinkronisasi sekaligus dan ketika panggilan sedang dilakukan, Anda dapat memiliki 8 saluran suara yang aktif semua paket pengiriman, dll.

Jika Anda mendapatkan jumlah IRQ tinggi tanpa ada panggilan, ini bisa menjadi gejala dari 2 hal buruk:

1. Ada masalah sinkronisasi dengan operator, Anda juga harus mendapatkan kualitas suara yang buruk.
2. Baris IRQ saling bertentangan, dalam hal ini ata_piix(ide / sata) Anda menggunakan baris yang sama dengan kartu BP410P, driver mungkin tidak begitu suka, dalam hal ini do memiliki jawaban sebelumnya yang disarankan coba dan ubah kartu ke slot lain .

Untuk debug Anda juga dapat mencoba menghapus kabel BRI dan melihat apakah ada bedanya.

Saya menemukan diri saya dalam situasi seperti itu beberapa waktu lalu, dan saya menulis sebuah irqtopalat kecil untuk memantau dengan mudah apa yang terjadi. Ini pada dasarnya sama dengan melakukan watch -n 1 cat /proc/interrupts, dengan output yang lebih bagus.

Kode sumber tersedia di sini: https://gitlab.com/elboulangero/irqtop