Skąd mam wiedzieć, które IRQ jest odpowiedzialne za wysokie użycie procesora

Przeniosłem serwer z jednej płyty głównej na drugą z powodu awarii kontrolera dysku.

Od tamtej pory zauważyłem, że 25% jednego z rdzeni zawsze trafia do IRQ, ale nie zdążyłem się dowiedzieć, który jest odpowiedzialny za to IRQ.

Jądro to Linux 2.6.18-194.3.1.el5 (CentOS). mpstat -P ALLprzedstawia:

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

To jest / 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

Jak mogę ustalić, które IRQ powoduje wysokie zużycie procesora?

Edytować:

Wyjście z 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

Cóż, ponieważ konkretnie pytasz, jak sprawdzić, które IRQ jest odpowiedzialne za liczbę mpstat, możesz założyć, że nie jest to lokalny licznik przerwań (LOC), ponieważ te liczby są dość równe, a mimo to mpstatpokazuje niektóre z tych wartości na poziomie 0% il.

Pozostawia to IRQ 0, który jest zegarem systemowym, o którym nie można nic zrobić, oraz IRQ 177, który jest powiązany ze sterownikiem b4xxp.

Domyślam się, że IRQ 177 będzie twoim winowajcą.

Jeśli powoduje to problem i chciałbyś zmienić swoje zachowanie, spróbuj:

1. wyłączanie oprogramowania używającego tej karty i sprawdzanie, czy liczba przerwań maleje.

2. wyjmując tę ​​kartę z systemu i zwalniając sterownik, i sprawdź, czy nastąpiła poprawa.

3. przenieś tę kartę do innego gniazda i sprawdź, czy to pomoże.

4. sprawdź zaktualizowane sterowniki lub poprawki oprogramowania.

Jeśli to nie problem, a byłeś tylko ciekawy, to kontynuuj. :)

watch -n1 -d cat /proc/interrupts

BP410P to karta ISDN z 4 liniami BRI, jeśli wszystkie cztery linie są połączone, powinieneś otrzymywać cztery pakiety synchronizacji na raz, a podczas nawiązywania połączeń możesz mieć 8 kanałów głosowych aktywnych dla wszystkich pakietów wysyłających itp.

Jeśli otrzymasz wysoką liczbę IRQ bez wykonywania połączeń, może to być objaw 2 złych rzeczy:

1. Wystąpił problem z synchronizacją z operatorem, powinieneś także uzyskać złą jakość głosu.
2. Linie IRQ są w konflikcie, w tym przypadku Twój ata_piix(ide / sata) korzysta z tej samej linii co karta BP410P, sterowniki mogą się nie bardzo podobać, w takim przypadku, czy poprzednia odpowiedź sugeruje, aby spróbować zmienić kartę na inne gniazdo .

Aby debugować, możesz także spróbować usunąć kable BRI i sprawdzić, czy to robi różnicę.

Jakiś czas temu znalazłem się w takiej sytuacji i napisałem małe irqtopnarzędzie do łatwego monitorowania tego, co się dzieje. Jest to w zasadzie to samo co robienie watch -n 1 cat /proc/interrupts, z ładniejszym wyjściem.

Kod źródłowy dostępny tutaj: https://gitlab.com/elboulangero/irqtop