デバイスのIRQ割り当てと割り込み発生状況を確認してトラブルを診断する手順

まず結論：/proc/interrupts でIRQ状態を一覧確認する

現在のシステムでどのデバイスがどのIRQを使っているか、割り込みが何回発生しているかは、/proc/interrupts を読み出すだけで把握できます。

cat /proc/interrupts

Ubuntu 22.04・AlmaLinux 9・Debian 12 など現代的なディストリビューションでの出力例は以下のとおりです。

           CPU0       CPU1       CPU2       CPU3
  0:         38          0          0          0  IR-IO-APIC   2-edge      timer
  1:          0          0          9          0  IR-IO-APIC   1-edge      i8042
  8:          1          0          0          0  IR-IO-APIC   8-edge      rtc0
  9:          0          0          0          0  IR-IO-APIC   9-fasteoi   acpi
 27:    1852341     423156          0          0  IR-IO-APIC  27-fasteoi   xhci_hcd
120:    4512890    3241567    2134890    1982341  IR-PCI-MSI 524288-edge   nvme0q0
121:    1234567     987654    1102341    1043210  IR-PCI-MSI 524289-edge   nvme0q1
169:   12345678    9876543   11234567   10123456  IR-PCI-MSI 409600-edge   eth0-TxRx-0
NMI:          0          0          0          0  Non-maskable interrupts
LOC:   23456789   23456790   23456791   23456792  Local timer interrupts
ERR:          0
MIS:          0

旧来の CentOS 5/6 時代はISAバスの IRQ 0〜15（16本）が主役でしたが、現代のサーバーでは PCI MSI（Message Signaled Interrupts）が主流です。IRQ番号が100番台・500番台になること、また NIC や NVMe が複数キューを持ち、それぞれ独立した IRQ を占有することが普通になっています。

出力の読み方：各列の意味

列の構成は左から「CPUコアごとの累積割り込みカウント」「割り込みコントローラの種別・IRQ番号・トリガー方式」「デバイス名」です。

CPU0〜N 列：そのコアが起動以来に受け取った割り込みの合計回数です。値が大きいこと自体は問題ではなく、特定コアへの極端な偏りや急激な増加が注目点になります。

コントローラ種別：IR-IO-APIC は従来型のI/O APIC 経由、IR-PCI-MSI はデバイスがメモリ書き込みで直接割り込みを通知する現代的な方式です。MSI/MSI-X ではピン共有がなく、「IRQ競合」という古典的な問題は事実上なくなっています。

末尾のデバイス名：nvme0q0 や eth0-TxRx-0 のようにキュー単位で表示されます。NVMe SSD や 10GbE NIC などは複数行にまたがって登場します。

NMI（Non-maskable interrupt）や ERR（割り込みエラー）の行も重要です。ERR や MIS の値がゼロ以外になっている場合はハードウェア異常のサインになります。

リアルタイムで割り込み急増を監視する

特定デバイスの割り込みが急増しているかどうかを確認するには watch を組み合わせます。

# 1秒ごとに更新（eth 関連の行だけ絞り込む例）
watch -n 1 'grep -i eth /proc/interrupts'

# NVMe も含めて広く見る場合
watch -n 1 'cat /proc/interrupts'

sar が使える環境なら、差分カウントをそのまま取得できます。

# 全IRQの1秒ごとの差分を表示（sysstat パッケージが必要）
sar -I ALL 1 5

ある運用現場では、ネットワークトラフィック急増時に eth0-TxRx-0 の割り込みが CPU0 に集中し、そのコアだけ100%に張り付くケースが発生しました。watch でリアルタイム確認することで、問題のある IRQ 番号をすぐに特定できます。

デバイスと IRQ の対応を PCI 情報から確認する

/proc/interrupts の出力だけではデバイスの正体が曖昧なとき、lspci と照合すると確実です。

# NIC・NVMe に絞って詳細表示
lspci -v | grep -A 12 'Ethernet\|Non-Volatile'

出力中の Interrupt: 行に IRQ 番号が表示されます。/proc/interrupts の行と番号を突き合わせることで「多く割り込んでいるのはどの物理デバイスか」が特定できます。

sysfs 経由でも確認できます。

# PCI デバイス一覧
ls /sys/bus/pci/devices/

# 特定デバイスの IRQ 番号（アドレスは lspci の出力に合わせる）
cat /sys/bus/pci/devices/0000:02:00.0/irq

割り込みが特定 CPU に偏っていたときの対処

すべての割り込みが CPU0 だけに集中しているケースは、irqbalance が停止している環境でよく見られます。

# irqbalance の状態確認（systemd 環境）
systemctl status irqbalance

# 停止していれば起動・自動起動を有効化
sudo systemctl enable --now irqbalance

irqbalance は割り込みを複数 CPU コアへ自動分散するデーモンです。インストール済みで止まっていた場合、起動するだけで負荷が平準化されることがあります。

高スループットが必要な NIC や NVMe では、あえて irqbalance を止め、CPU アフィニティを手動設定する運用もあります。

# IRQ 169 を CPU2 だけに固定する例（ビットマスク: CPU2 = 0b0100 = 4）
echo 4 | sudo tee /proc/irq/169/smp_affinity

# CPU 番号のリスト形式で指定する場合（こちらのほうが直感的）
echo 2 | sudo tee /proc/irq/169/smp_affinity_list

# 現在の割り当てを確認
cat /proc/irq/169/smp_affinity_list

この設定は再起動すると元に戻ります。恒久化するには /etc/irqbalance の設定ファイルで対象 IRQ を除外するか、起動時スクリプトに組み込む必要があります。

現代的な IRQ 管理の注意点

カウントは累積値：/proc/interrupts の数値は起動からの合計です。増加速度を見るには watch で差分を目視するか sar -I ALL を使います。単に値が大きいだけでは問題の有無は判断できません。

仮想マシン環境の注意：KVM・VMware・Hyper-V のゲスト OS では、ホストとは異なる仮想割り込み構成が見えます。ゲスト内の /proc/interrupts は仮想デバイスの情報であり、物理 NIC や物理ディスクの実際の IRQ とは別物です。

MSI-X 環境では「IRQ 競合」は起きない：カーネル 5.x 以降・現代的なサーバーハードウェアでは割り込みの多くが MSI-X で処理されます。デバイスごとに専用のメッセージベース割り込みが割り当てられるため、旧来の「IRQ を複数デバイスで共有して競合する」問題はほぼ解消されています。問題になるのは特定 CPU への偏りや、処理しきれない割り込みレートの急増です。

ERR と MIS の値に注意：出力末尾の ERR（割り込みエラー）や MIS（missed interrupts）がゼロ以外になっている場合は、ハードウェア障害やドライバの問題を疑う手がかりになります。dmesg や journalctl -k と合わせて確認してください。