¿Cómo puedo saber qué IRQ es responsable del uso elevado de la CPU?

20

He movido un servidor de una placa base a otra debido a una falla del controlador de disco.

Desde entonces, he notado que constantemente el 25% de uno de los núcleos va siempre a IRQ, sin embargo, no he logrado saber cuál es el IRQ responsable de eso.

El núcleo es un Linux 2.6.18-194.3.1.el5 (CentOS). mpstat -P ALLmuestra:

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

Este es el / proc / interrupciones

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

¿Cómo puedo identificar qué IRQ está causando el uso elevado de la CPU?

Editar:

Salida de 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

kernel centos cpu

— eproyectos
fuente

1

¿Es este un servidor de asterisco? que dmesg | grep -i b4xxpmuestra

— Tim Kennedy el

@TimKennedy: sí, lo es. He editado mi pregunta para mostrar qué muestra dmesg.

— eproyectos el

21

Bueno, ya que está preguntando específicamente cómo saber qué IRQ es responsable del número mpstat, puede suponer que no es el temporizador de interrupción local (LOC), ya que esos números son bastante iguales y, sin embargo, mpstatmuestra algunos de esos cpus al 0% irq.

Eso deja IRQ 0, que es el temporizador del sistema, y sobre el que no puede hacer nada, e IRQ 177, que está vinculado a su controlador b4xxp.

Supongo que IRQ 177 sería tu culpable.

Si esto está causando un problema, y desea cambiar el comportamiento que ve, intente:

deshabilite el software que usa esa tarjeta y vea si las interrupciones disminuyen.
quitando esa tarjeta del sistema y descargando el controlador, y vea si hay una mejora.
mueva esa tarjeta a otra ranura y vea si eso ayuda.
busque controladores o parches actualizados para el software.

Si no es un problema, y solo tenía curiosidad, continúe. :)

— Tim Kennedy
fuente

El problema surgió después de cambiar el MB. Quizás valga la pena intentar cambiar la tarjeta a otra ranura PCI.

— eproyectos el

consulte esta página: voip-info.org/wiki/view/Asterisk+PCI+bus+ Solución de problemas de buena información para identificar problemas, incluidos los problemas de IRQ.

— Tim Kennedy el

4

watch -n1 -d cat /proc/interrupts

— sjas
fuente

Esto no responde a la pregunta real que hace OP.

— heemayl

De esa manera, verá los cambios de interrupción más, sé que me ayudó a solucionar exactamente el problema que se describió en el tema.

— sjas

4

BP410P es una tarjeta RDSI con 4 líneas BRI, si las cuatro líneas están conectadas, debería recibir cuatro paquetes de sincronización a la vez y cuando se realizan llamadas, puede tener 8 canales de voz activos todos los paquetes de envío, etc.

Si obtiene un recuento alto de IRQ sin hacer ninguna llamada, esto podría ser un síntoma de 2 cosas malas:

Hay un problema de sincronización con el operador, también debería obtener una mala calidad de voz.
Las líneas IRQ son conflictivas, en este caso su ata_piix(ide / sata) está usando la misma línea que tiene la tarjeta BP410P, los controladores pueden no gustarle mucho, en este caso la respuesta anterior sugiere probar y cambiar la tarjeta a otra ranura .

Para depurar, también puede intentar quitar los cables BRI y ver si hace la diferencia.

— led42
fuente

+1Revisaré tus consejos. Gracias

— eproyectos

1

Wow, impactante. La última vez que tuve que jugar card-jockey fue a mediados de los noventa. Ni siquiera he usado el término 'card-jockey' desde entonces. Pensé que todo esto había quedado atrás, con APIC, MSI, etc.

— Alexios

2

Me encontré en una situación así hace algún tiempo, y escribí una pequeña irqtopherramienta para monitorear fácilmente lo que está sucediendo. Básicamente es lo mismo que hacer un watch -n 1 cat /proc/interrupts, con una salida más agradable.

Código fuente disponible aquí: https://gitlab.com/elboulangero/irqtop

— elboulangero
fuente