Как я могу узнать, какой IRQ отвечает за высокую загрузку процессора

Я перенес сервер с одной материнской платы на другую из-за сбоя контроллера диска.

С тех пор я заметил, что постоянно 25% одного из ядер всегда идут на IRQ, однако я так и не смог узнать, какой 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 / 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

Как я могу определить, какой 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 без каких-либо звонков, это может быть признаком двух плохих вещей:

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

Для отладки вы также можете попробовать отсоединить кабели BRI и посмотреть, что изменится.

Некоторое время назад я попал в такую ​​ситуацию и написал небольшой irqtopинструмент, чтобы легко отслеживать, что происходит. Это в основном то же самое, что и watch -n 1 cat /proc/interruptsс более хорошим результатом.

Исходный код доступен здесь: https://gitlab.com/elboulangero/irqtop