由 dawei 这里记录的是自启动以来，每个CPU处理各类中断的数量。第一列是中断号，最后一列是对应的设备名。从上面可以看到： eth0所出发的中断全部都是 CPU0在处理，而CPU0所处理的中断请求中，主要是eth0和LOC中断。有时我们会看到几个CPU对同一个中断类型所处理的的请求数相差无几(比如上面的LOC)，这并不一定是说多个CPU会轮流处理同一个中断，而是因为这里记录的是“自启动以来”的统计，中间可能因为irq balancer重新分配过处理中断的CPU。
解决思路
现在的多数Linux系统中都有IRQ Balance这个服务(服务程序一般是 /usr/sbin/irqbalance)，它可以自动调节分配各个中断与CPU的绑定关系，以避免所有中断的处理都集中在少数几个CPU上。在某些情况下，这个IRQ Balance反而会导致问题，会出现 irqbalance 这个进程反而自身占用了较高的CPU(当然也就影响了业务系统的性能)。
首先要看该网卡的中断当前是否已经限定到某些CPU了?具体是哪些CPU?
根据上面 /proc/interrupts 的内容我们可以看到 eth0 的中断号是74，然后我们来看看该中断号的CPU绑定情况或者说叫亲和性 affinity。
$ sudo cat /proc/irq/74/smp_affinity
ffffff
这个输出是一个16进制的数值，0xffffff = '0b111111111111111111111111'，这就意味着这里有24个CPU，所有位都为1表示所有CPU都可以被该中断干扰。
修改配置的方法:(设置为2表示将该中断绑定到CPU1上，0x2 = 0b10，而第一个CPU为CPU0)
echo 2 > /proc/irq/74/smp_affinity