Comment puis-je savoir quelle IRQ est responsable de l'utilisation élevée du processeur

J'ai déplacé un server d'une carte mère à l'autre en raison d'une défaillance du controller de disque.

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

Le kernel est un Linux 2.6.18-194.3.1.el5 (CentOS). mpstat -P ALL montre:

 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 quelle IRQ cause l'utilisation élevée du processeur?

Modifier:

Sortie de dmesg | grep -i b4xxp 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 

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

Cela laisse IRQ 0, qui est le temporisateur 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 un problème et que vous souhaitez modifier le comportement de votre site, 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 vers un autre location et voyez si cela vous aide.

  4. vérifiez les pilotes ou les correctifs mis à jour pour le logiciel.

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

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

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

  1. Il y a un problème de synchronisation avec l'opérateur, vous devriez également avoir 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 ça, dans ce cas la réponse précédente a suggéré d'essayer de changer la carte fente.

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

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

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

J'espère que cela t'aides 🙂

 watch -n1 -d cat /proc/interrupts