要查看并调整linux网络接口的irq亲和性，首先需识别网络接口对应的irq号，通过grep命令在/proc/interrupts中查找；其次查看当前irq的cpu亲和性，使用cat命令读取/proc/irq/
查看Linux网络接口的IRQ亲和性，通常我们会关注 /proc/irq/ 这个文件，它以十六进制掩码的形式表示中断可以运行在哪些CPU核心上。更直观的方式是查看 smp_affinity_list，它直接列出CPU核心编号。中断亲和性调整是Linux系统性能优化的一个重要手段，尤其对于高并发网络服务而言，它能有效平衡CPU负载，提升网络吞吐量和降低延迟。
解决方案
要查看并调整Linux网络接口的IRQ亲和性，你需要了解以下步骤：
-
识别网络接口对应的IRQ号： 通常，一个网络接口，特别是多队列网卡，会有多个中断号。你可以通过
grep命令在/proc/interrupts中查找。 例如，查找eth0的IRQ：
grep eth0 /proc/interrupts
你会看到类似这样的输出：
30: 1234567 0 0 0 IO-APIC 30-edge eth0 31: 0 8765432 0 0 IO-APIC 31-edge eth0-rx-0 32: 0 0 9876543 0 IO-APIC 32-edge eth0-rx-1
这里的
30,31,32就是IRQ号。现代网卡通常会为每个接收队列（rx-N）分配一个独立的IRQ。
-
查看当前IRQ的CPU亲和性： 找到IRQ号后，你可以查看它当前绑定到哪些CPU核心。
cat /proc/irq/31/smp_affinity cat /proc/irq/31/smp_affinity_list
smp_affinity输出的是一个十六进制掩码，例如f表示可以运行在CPU0、CPU1、CPU2、CPU3上（二进制1111）。smp_affinity_list则直接列出CPU核心编号，例如0-3或0,1,2,3。 -
调整IRQ的CPU亲和性： 如果你想将某个IRQ绑定到特定的CPU核心，比如将IRQ 31绑定到CPU 1：
echo 2 > /proc/irq/31/smp_affinity
这里的
2是十六进制，代表二进制0010，表示CPU 1。 如果你想绑定到CPU 1和CPU 2：echo 6 > /proc/irq/31/smp_affinity
这里的
6是十六进制，代表二进制0110，表示CPU 1和CPU 2。 使用smp_affinity_list更直观：echo 1 > /proc/irq/31/smp_affinity_list # 绑定到CPU 1 echo 1,2 > /proc/irq/31/smp_affinity_list # 绑定到CPU 1和CPU 2
注意： 很多Linux发行版默认会运行
irqbalance服务。这个服务会动态地调整中断亲和性以平衡负载。如果你手动设置了亲和性，irqbalance可能会在一段时间后将其改回去。在进行精细调优时，通常需要禁用irqbalance。systemctl stop irqbalance systemctl disable irqbalance
生产环境中，通常会有一个脚本来持久化这些设置，例如在
/etc/rc.local或 systemd service 中执行这些echo命令。
为什么我们需要关心网络接口的IRQ亲和性？
谈到网络性能，很多人会先想到网卡带宽、CPU主频或者内存大小，但往往忽略了中断处理这个细节。我记得有一次，一个高并发的Web服务，IOPS总是上不去，排查了半天磁盘、内存，最后发现是网卡中断处理把一个CPU核心打满了，那时候才真正意识到这个小细节的重要性。
核心原因在于，当网络流量涌入时，网卡会产生大量中断，通知CPU有数据需要处理。如果这些中断都集中在少数几个CPU核心上，即使其他核心很空闲，这几个核心也会成为瓶颈。这就像一条高速公路，所有车辆都挤在一个收费站，而旁边几个收费站却空着。
具体来说，关心IRQ亲和性有几个好处：
- 避免CPU热点： 将中断处理分散到不同的CPU核心，可以避免单个核心负载过高，形成性能瓶颈。
- 提高缓存命中率： 当中断处理和后续的数据处理（比如网络协议栈、应用层数据处理）发生在同一个CPU核心上时，可以更好地利用CPU缓存，减少内存访问延迟。这对于数据密集型应用尤其重要。
- NUMA架构优化： 在非均匀内存访问（NUMA）架构的服务器上，将网络卡的中断绑定到与网卡物理位置接近的CPU节点，可以显著减少跨NUMA节点访问内存的延迟，从而提升整体性能。
- 降低延迟和抖动： 更均衡的中断处理可以使网络包的处理更加及时和稳定，从而降低网络延迟和抖动。
如何合理规划网络接口中断与CPU核心的绑定策略？
这块其实没有一个“放之四海而皆准”的银弹，很多时候需要结合你服务器的实际硬件配置（尤其是NUMA架构）和业务负载来做决策。我个人经验是，先从最简单的“一个队列一个CPU”开始，然后根据mpstat的输出慢慢微调。
以下是一些规划策略的思考点：
-
识别并利用多队列网卡： 现代高性能网卡几乎都支持多队列（Multi-queue）功能。这意味着网卡可以将接收到的网络数据分成多个队列，每个队列可以独立地产生中断，并由不同的CPU核心处理。这是进行中断绑定的前提。你可以用
ethtool -l查看网卡支持的队列数，并用ethtool -L来设置合并队列的数量。combined - CPU核心隔离： 对于一些关键服务，你可能希望将它们运行在特定的CPU核心上，而将网卡中断绑定到另外的CPU核心，以避免中断处理抢占应用进程的CPU资源。
-
NUMA感知绑定： 如果你的服务器是NUMA架构（可以通过
numactl --hardware查看），尝试将网卡的中断绑定到与网卡物理上位于同一NUMA节点上的CPU核心。这样可以减少跨节点通信的开销，降低内存访问延迟。 - 避免CPU 0： CPU 0通常承载了大量系统级中断和内核任务。在高负载场景下，尽量避免将高流量网卡的中断绑定到CPU 0，以防其成为瓶颈。
- 平衡负载： 如果网卡有多个队列，可以将每个队列的中断均匀地分散到不同的CPU核心上。例如，一个四队列网卡，可以分别绑定到CPU 1、CPU 2、CPU 3、CPU 4，从而实现中断处理的并行化。
-
考虑软中断（SoftIRQ）： 中断处理分为硬中断（IRQ）和软中断（SoftIRQ）。硬中断处理通常很快，只是通知CPU有事发生。真正的数据包处理大部分是在软中断上下文中完成的。软中断的负载也需要被关注，它们同样会消耗CPU资源。
ksoftirqd进程负责处理软中断，它通常会在所有CPU核心上运行。
中断亲和性调整后，如何验证效果并进行故障排查？
别指望一次调整就完美，我遇到过很多次，自以为是的优化，结果性能反而更差了。这时候就得老老实实地用 mpstat、top 这些工具去观察，看哪个CPU“忙”得不正常，%irq 是不是飙高了。很多时候，irqbalance 这个“好心办坏事”的家伙是罪魁祸首，它会默默地把你的优化给“优化”回去。
验证效果和故障排查是调整过程中不可或缺的环节：
-
确认设置是否生效： 最直接的方式就是再次
cat /proc/irq/，确保你的设置被系统接受并保持。如果发现设置被重置，很可能是/smp_affinity_list irqbalance在作祟。 -
监控CPU利用率：
-
mpstat -P ALL 1：这个命令可以实时显示每个CPU核心的利用率，尤其是关注%irq（硬中断处理时间）和%softirq（软中断处理时间）。如果调整后，之前负载过高的核心的%irq或%softirq下降，并且负载分散到了其他核心，那就说明调整有效果。 -
top或htop：从整体层面观察CPU负载是否更均衡，是否有某个ksoftirqd/N进程（其中N是CPU编号）的CPU占用率异常高。
-
-
监控网络性能指标：
-
吞吐量： 使用
iperf3或netperf等工具进行网络性能测试，比较调整前后的带宽表现。 - 延迟： 对于对延迟敏感的应用，观察其平均延迟和抖动是否有所改善。
- 丢包率： 检查是否有因中断处理不过来导致的丢包情况。
-
吞吐量： 使用
-
检查中断计数： 持续
cat /proc/interrupts，观察特定IRQ的中断次数在各个CPU上的分布，看是否符合你的绑定预期。 -
故障排查：
- 性能不升反降： 这很常见。可能的原因是：你将中断绑定到了一个已经很繁忙的CPU；或者在NUMA系统上，你将中断绑定到了错误的NUMA节点；或者你绑定的CPU核心数量不足以处理所有中断。
-
中断没有按预期绑定： 再次强调，检查
irqbalance服务是否在运行。如果它在运行，它会周期性地重新平衡中断，覆盖你的手动设置。在精细调优时，通常需要禁用它。 -
CPU利用率不均衡： 即使绑定了，如果网卡队列数量不足，或者应用层没有充分利用多核，可能仍然会出现部分核心负载过高的情况。这可能需要从网卡配置（如
ethtool -L）和应用层面进行优化。 -
系统日志： 检查
dmesg或journalctl -xe，看看是否有与中断、网卡或CPU相关的错误信息。有时候，内核版本或驱动问题也可能导致意外行为。
