Як я можу знати, який IRQ відповідає за високе використання процесора

Я перемістив сервер з однієї материнської плати на іншу через несправність дискового контролера.

З того часу я помітив, що постійно 25% одного з ядер завжди йде на IRQ, але я не встиг дізнатися, хто за це відповідає.

Ядро є Linux 2.6.18-194.3.1.el5 (CentOS). mpstat -P ALLпоказує:

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

Це / proc / перериває

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

Як я можу визначити, який IRQ викликає велике використання процесора?

Редагувати:

Вихід від 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

Отже, оскільки ви спеціально запитуєте, як дізнатися, який IRQ відповідає за число в mpstat, ви можете припустити, що це не локальний таймер переривання (LOC), оскільки ці числа досить рівні, і все ж mpstatпоказує, що деякі з цих процесорів становлять 0% irq

Це залишає IRQ 0, який є системним таймером і з яким ви нічого не можете зробити, і IRQ 177, який прив’язаний до вашого драйвера b4xxp.

Думаю, IRQ 177 стане вашим винуватцем.

Якщо це спричиняє проблеми, і ви хочете змінити свою поведінку, спробуйте:

1. вимкнення програмного забезпечення, яке використовує цю карту, і перевірити, чи зменшуються переривання.

2. вийміть цю карту із системи та вивантажте драйвер і подивіться, чи є покращення.

3. перемістіть цю карту в інший слот і подивіться, чи це допомагає.

4. перевірити наявність оновлених драйверів чи виправлень програмного забезпечення.

Якщо це не проблема, а вам просто цікаво, продовжуйте. :)

watch -n1 -d cat /proc/interrupts

BP410P - це карта ISDN з 4 лініями BRI, якщо всі чотири лінії підключені, ви повинні отримувати чотири пакети синхронізації одночасно, і при здійсненні дзвінків ви можете мати 8 голосових каналів, активні всі пакети відправки тощо

Якщо ви отримаєте високий показник IRQ, не здійснюючи дзвінків, це може бути симптомом 2 поганих речей:

1. Виникла проблема із синхронізацією з оператором, ви також маєте погану якість голосу.
2. Рядки IRQ суперечать ata_piixодин одному , у цьому випадку ваш (ide / sata) використовує той самий рядок, що має карту BP410P, драйверам це не дуже подобається. У цьому випадку попередня відповідь запропонувала спробувати змінити карту на інший слот .

Для налагодження ви також можете спробувати видалити кабелі BRI і побачити, чи це має значення.

Я опинився в такій ситуації деякий час тому, і я написав невеликий irqtopінструмент, щоб легко слідкувати за тим, що відбувається. Це в основному те саме, що робити watch -n 1 cat /proc/interrupts, з кращим результатом.

Вихідний код доступний тут: https://gitlab.com/elboulangero/irqtop