Làm thế nào tôi có thể biết IRQ nào chịu trách nhiệm sử dụng CPU cao

Tôi đã chuyển một máy chủ từ bo mạch chính này sang bo mạch khác do lỗi bộ điều khiển đĩa.

Kể từ đó, tôi nhận thấy rằng liên tục 25% một trong số các lõi luôn luôn chuyển sang IRQ tuy nhiên tôi đã tự xoay sở để biết IRQ nào chịu trách nhiệm cho việc đó.

Nhân là Linux 2.6,18-194.3.1.el5 (CentOS). mpstat -P ALLtrình diễn:

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

Đây là / Proc / ngắt

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

Làm cách nào để xác định IRQ nào gây ra việc sử dụng CPU cao?

Chỉnh sửa:

Đầu ra từ 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

Chà, vì bạn đặc biệt hỏi làm thế nào để biết IRQ nào chịu trách nhiệm cho số đó mpstat, bạn có thể cho rằng đó không phải là bộ đếm thời gian ngắt cục bộ (LỘC), vì những con số đó khá bằng nhau, và mpstatcho thấy một số cpus đó ở mức 0% irq.

Rời khỏi IRQ 0, đó là bộ đếm thời gian hệ thống và bạn không thể làm gì được, và IRQ 177, được gắn với trình điều khiển b4xxp của bạn.

Tôi đoán là IRQ 177 sẽ là thủ phạm của bạn.

Nếu điều này gây ra sự cố và bạn muốn thay đổi hành vi mà bạn thấy, hãy thử:

1. vô hiệu hóa phần mềm sử dụng thẻ đó và xem các ngắt có giảm không.

2. gỡ thẻ đó ra khỏi hệ thống và dỡ trình điều khiển và xem có cải thiện không.

3. di chuyển thẻ đó sang một khe khác và xem nếu nó giúp.

4. kiểm tra các trình điều khiển cập nhật hoặc các bản vá cho phần mềm.

Nếu đó không phải là vấn đề và bạn chỉ tò mò thì hãy tiếp tục. :)

watch -n1 -d cat /proc/interrupts

BP410P là thẻ ISDN có 4 BRI Lines, nếu cả bốn dòng được kết nối, bạn sẽ nhận được bốn gói đồng bộ hóa cùng một lúc và khi các cuộc gọi được thực hiện, bạn có thể có 8 kênh thoại hoạt động tất cả các gói gửi, v.v.

Nếu bạn có số lượng IRQ cao mà không có bất kỳ cuộc gọi nào được thực hiện thì đây có thể là triệu chứng của 2 điều xấu:

1. Có vấn đề đồng bộ với nhà điều hành, bạn cũng sẽ nhận được chất lượng giọng nói kém.
2. Các dòng IRQ đang xung đột, trong trường hợp này ata_piix(ide / sata) của bạn đang sử dụng cùng một dòng có thẻ BP410P, các trình điều khiển có thể không thích điều đó lắm, trong trường hợp này có câu trả lời trước đó đề nghị thử và thay đổi thẻ sang một khe khác .

Để gỡ lỗi, bạn cũng có thể thử tháo cáp BRI và xem liệu nó có tạo ra sự khác biệt không.

Tôi đã thấy mình trong tình huống như vậy một thời gian trước đây và tôi đã viết một irqtopcông cụ nhỏ để theo dõi dễ dàng những gì đang diễn ra. Về cơ bản, nó giống như làm một watch -n 1 cat /proc/interrupts, với đầu ra đẹp hơn.

Mã nguồn có sẵn ở đây: https://gitlab.com/elboulangero/irqtop