网卡中断与CPU的绑定问题_网卡与cpu联系的两种方法-CSDN博客

在Linux的网络调优方面，如果你发现网络流量上不去，那么有一个方面需要去查一下：网卡处理网络请求的中断是否被绑定到单个CPU（或者说跟处理其它中断的是同一个CPU）。

先说一下背景

网卡与操作系统的交互一般有两种方式，

一种是中断（IRQ，网卡在收到了网络信号之后，主动发送中断到CPU，而CPU将会立即停下手边的活以便对这个中断信号进行分析），
另一种叫DMA（Direct Memory Access, 也就是允许硬件在无CPU干预的情况下将数据缓存在指定的内存空间内，在CPU合适的时候才处理）

——记得在10多年前开始玩电脑的时候就知道DMA是效率比较高的方式了。但是，这么多年过去了，在网卡方面，大部分还是在用IRQ方式（据说DMA技术仅仅被应用在少数高端网卡上; 另一个说法是：DMA方式会使外部设备的控制器独占PCI总线，从而CPU无法与外部设备进行交互，这对通用型操作系统Linux来说，是很难接收的，所以DMA方式在Linux内核里使用得很少）。

但是（再来一个但是），在现在的对称多核处理器（SMP）上，一块网卡的IRQ还是只有一个CPU来响应，其它CPU无法参与，如果这个CPU还要忙其它的中断（其它网卡或者其它使用中断的外设（比如磁盘）），那么就会形成瓶颈。

问题判定

网上不少讲这个问题的文章都是直接让查询IRQ跟CPU的绑定情况，甚至直接修改。但我们应该先判断我们的系统是不是受这个问题影响，然后再来看怎么解决。

首先，让你的网络跑满（比如对于MySQL/MongoDB服务，可以通过客户端发起密集的读操作; 或者执行一个i大文件传送任务）

第一个要查明的是：是不是某个CPU在一直忙着处理IRQ？

这个问题我们可以从

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都在处理哪个（些）中断？

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——当然，也可能是谁手工调节过）。

解决问题

首先说明几点：

首先应该根据上面的诊断方法查明当前系统是不是受这个原因影响，如果不是，那么就没有必要往下看了;
现在的多数Linux系统中已经有了IRQ Balance这个服务（服务程序一般是 /usr/sbin/irqbalance），它可以自动调节分配各个中断与CPU的绑定关系，以避免所有中断的处理都集中在少数几个CPU上;
在某些情况下，这个IRQ Balance反而会导致问题，会出现 irqbalance 这个进程反而自身占用了较高的CPU（当然也就影响了业务系统的性能）[参考: mongodb性能问题及原理分析 ]

下面来说手工将中断限定到少数几个CPU的方法。

首先当然要查明，该网卡的中断当前是否已经限定到某些CPU了？具体是哪些CPU？

根据上面 /proc/interrupts 的内容我们可以看到 eth0 的中断号是74，然后我们来看看该中断号的CPU绑定情况（或者说叫亲和性 affinity）

$ sudo cat /proc/irq/74/smp_affinity
ffffff

这个输出是一个16进制的数值，0xffffff = ‘0b111111111111111111111111’，这就意味着这里有24个CPU，所有位都为1表示所有CPU都可以被该中断干扰。

另一个例子:

$ sudo cat /proc/irq/67/smp_affinity
00000001

这个例子说明，只有CPU0处理编号为67的中断。

修改配置的方法：

我们可以用 echo 2 > /proc/irq/74/smp_affinity 的方法来修改这个设置（设置为2表示将该中断绑定到CPU1上，0x2 = 0b10，而第一个CPU为CPU0）