转:[Linux 性能调优] 网卡中断与CPU的绑定问题

https://www.cnblogs.com/bamanzi/p/linux-irq-and-cpu-affinity.html

1.监控终端数量

mpstat -P ALL 1 的输出中查明：里面的 %irq一列即说明了CPU忙于处理中断的时间占比

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

上面的例子中，第四个CPU有25.63%时间在忙于处理中断（这个数值还不算高，如果高达80%（而同时其它CPU这个数值很低）以上就说明有问题了），后面那个 intr/s 也说明了CPU每秒处理的中断数（从上面的数据也可以看出，其它几个CPU都不怎么处理中断）。

然后我们就要接着查另外一个问题：这个忙于处理中断的CPU都在处理哪个（些）中断？

2.查看中断数量

[popexizhi：动态变动监控方式:watch -d "cat /proc/interrupts|sed 's/        /,/g'|sed 's/ //g'"]

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

这里记录的是自启动以来，每个CPU处理各类中断的数量（第一列是中断号，最后一列是对应的设备名）[详细说明: E.2.10 /proc/interrupts - Deployment Guide - RedHat Enterprise Linux 6 )，从上面可以看到： eth0所出发的中断全部都是 CPU0在处理，而CPU0所处理的中断请求中，主要是eth0和LOC中断。（有时我们会看到几个CPU对同一个中断类型所处理的的请求数相差无几（比如上面的LOC一行），这并不一定是说多个CPU会轮流处理同一个中断，而是因为这里记录的是“自启动以来”的统计，中间可能因为irq balancer重新分配过处理中断的CPU——当然，也可能是谁手工调节过）