共计 1523 个字符，预计需要花费 4 分钟才能阅读完成。
这篇文章主要为大家展示了“Linux 中如何解决网卡中断与 CPU 绑定问题”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让丸趣 TV 小编带领大家一起研究并学习一下“Linux 中如何解决网卡中断与 CPU 绑定问题”这篇文章吧。
在 Linux 的网络调优方面，如果你发现网络流量上不去，那么有一个方面需要去查一下：网卡处理网络请求的中断是否被绑定到单个 CPU 或跟处理其它中断的是同一个 CPU。
网卡与操作系统的交互方式
网卡与操作系统的交互一般有两种方式：
1. 中断 IRQ
网卡在收到了网络信号之后，主动发送中断到 CPU，而 CPU 将会立即停下手边的活以便对这个中断信号进行分析;
2. DMA(Direct Memory Access)
也就是允许硬件在无 CPU 干预的情况下将数据缓存在指定的内存空间内，在 CPU 合适的时候才处理;
现在的对称多核处理器 (SMP) 上，一块网卡的 IRQ 还是只有一个 CPU 来响应，其它 CPU 无法参与，如果这个 CPU 还要忙其它的中断(其它网卡或者其它使用中断的外设(比如磁盘))，那么就会形成瓶颈。
检查环境
首先，让网络跑满。如：对于 MySQL/MongoDB 服务，可以通过客户端发起密集的读操作 或执行一个大文件传送任务。查明是不是某个 CPU 在一直忙着处理 IRQ?
从 mpstat -P ALL 1 输出里面的 %irq 一列即说明了哪个 CPU 忙于处理中断的时间占比;
上面的例子中，第四个 CPU 有 25.63% 时间在忙于处理中断，后面 intr/s 也说明了 CPU 每秒处理的中断数。从上面的数据可以看出，其它几个 CPU 都不怎么处理中断。
那么，这些忙于处理中断的 CPU 都在处理哪些中断?
这里记录的是自启动以来，每个 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以上是“Linux 中如何解决网卡中断与 CPU 绑定问题”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！
