Comment savoir quel IRQ est responsable d'une utilisation élevée du processeur

20

J'ai déplacé un serveur d'une carte mère à une autre en raison d'une défaillance du contrôleur de disque.

Depuis lors, j'ai remarqué qu'en permanence 25% de l'un des cœurs va toujours à l'IRQ, mais je n'ai pas réussi à savoir quel est l'IRQ responsable de cela.

Le noyau est un Linux 2.6.18-194.3.1.el5 (CentOS). mpstat -P ALLspectacles:

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

C'est le / 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

Comment puis-je identifier l'IRQ à l'origine de l'utilisation élevée du processeur?

Éditer:

Sortie 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
la source
1
est-ce un serveur astérisque? qu'est-ce que cela dmesg | grep -i b4xxpmontre?
Tim Kennedy
@ TimKennedy: oui c'est le cas. J'ai édité ma question pour montrer ce que montre dmesg.
eproyectos

Réponses:

21

Eh bien, puisque vous demandez spécifiquement comment savoir quel IRQ est responsable du nombre mpstat, vous pouvez supposer que ce n'est pas le temporisateur d'interruption local (LOC), car ces nombres sont assez égaux, et pourtant mpstatmontre certains de ces processeurs à 0% irq.

Cela laisse IRQ 0, qui est le minuteur du système, et sur lequel vous ne pouvez rien faire, et IRQ 177, qui est lié à votre pilote b4xxp.

Je suppose que l'IRQ 177 serait votre coupable.

Si cela pose problème et que vous souhaitez modifier le comportement que vous voyez, essayez:

  1. désactiver le logiciel qui utilise cette carte et voir si les interruptions diminuent.

  2. retirer cette carte du système et décharger le pilote, et voir s'il y a une amélioration.

  3. déplacez cette carte dans un autre emplacement et voyez si cela vous aide.

  4. recherchez les pilotes ou correctifs mis à jour pour le logiciel.

Si ce n'est pas un problème et que vous étiez simplement curieux, continuez. :)

Tim Kennedy
la source
Le problème est survenu après avoir changé le MB. Peut-être que le changement de la carte vers un autre emplacement PCI mérite d'être essayé.
eproyectos
consultez cette page: voip-info.org/wiki/view/Asterisk+PCI+bus+Troubleshooting bonnes informations pour identifier les problèmes, y compris les problèmes d'IRQ.
Tim Kennedy
4 
watch -n1 -d cat /proc/interrupts
sjas
la source
Cela ne répond pas à la question que pose OP.
heemayl
De cette façon, vous voyez le plus de changements d'interruption, je sais que cela m'a aidé lors du dépannage exact du problème décrit dans la rubrique.
sjas
4

BP410P est une carte RNIS avec 4 lignes BRI, si les quatre lignes sont connectées, vous devriez recevoir quatre paquets de synchronisation à la fois et lorsque des appels sont en cours, vous pouvez avoir 8 canaux de voix actifs tous les paquets d'envoi, etc.

Si vous obtenez un nombre d'IRQ élevé sans aucun appel, cela pourrait être le symptôme de 2 mauvaises choses:

  1. Il y a un problème de synchronisation avec l'opérateur, vous devriez également obtenir une mauvaise qualité vocale.
  2. Les lignes IRQ sont en conflit, dans ce cas, votre ata_piix(ide / sata) utilise la même ligne que la carte BP410P, les pilotes pourraient ne pas aimer beaucoup, dans ce cas, la réponse précédente a suggéré d'essayer de changer la carte dans un autre emplacement .

Pour déboguer, vous pouvez également essayer de retirer les câbles BRI et voir si cela fait une différence.

led42
la source
+1Je vérifierai vos conseils. Merci
eproyectos
1
Wow, choquant. La dernière fois que j'ai dû jouer au jockey de cartes, c'était au milieu des années 90. Je n'ai même pas utilisé le terme de «card-jockey» depuis. Je pensais que tout cela était bien derrière nous, avec les APIC, les MSI, etc.
Alexios
2

Je me suis retrouvé dans une telle situation il y a quelque temps, et j'ai écrit un petit irqtopoutil pour suivre facilement ce qui se passe. C'est essentiellement la même chose que de faire un watch -n 1 cat /proc/interrupts, avec une sortie plus agréable.

Code source disponible ici: https://gitlab.com/elboulangero/irqtop

elboulangero
la source