前言
前段时间在泰山服务器上进行性能测试，预期是应用进程能够占满机器大部分 CPU。但实际上，应用进程在服务器上的 CPU 使用率远不及预期。后来发现是网卡绑核的问题，调整网卡队列绑核方式后，整体性能达到预期。
解决方案
测试多种绑核方式后发现，HNS3 网卡可以通过每 2 个网卡队列与 1 个 CPU 核心绑定的方式平衡软中断 CPU 使用率。
假设系统计划使用 10 个 CPU 核心用于处理网络中断，则开启 20 个网卡队列，队列 0、队列 1 绑定到 CPU 0，队列 2、队列 3 绑定到 CPU 1，以此类推。
按照新的方式绑核后，处理网络中断的 CPU 核心使用率表现相对正常，应用性能发挥与预期相近。
排查过程
应用程序运行环境与方式
服务器环境是泰山服务器，使用的网卡是板载的 HNS3，根据接口区分型号 TM210 TM280。
考虑应用程序是一个 I/O 和 CPU 密集的程序，且服务器 CPU 较多，应用程序通过 numactl 绑核运行在第 12-128 核心上（117 个核心），第 2-11 核心（10 个核心）与网卡队列绑定用于处理网络中断。
通过常用的工具查看 CPU 使用率。
另一个应用程序运行在第 19-128 核心（112 个核心），第 1-18 核心（18 个核心）与网卡队列绑定用于处理网络中断。
在性能测试期间，10 个用于处理网络中断的 CPU 核心，只有其中的 5 个 CPU 核心几乎满载，另外 5 个核心使用率较低，导致该节点部署的应用程序在压测过程中性能表现相对较差。
检查是否存在 irqbalance 进程
曾经有遇到过一个问题，将网卡队列指定 CPU 绑核后，大约 10 秒后，网卡中断处理的 CPU 又变成了随机绑定 CPU。后来发现，irqbalance 的 service 显示未启动，但是却看到有一个 irqbalance 进程正在运行。结束进程后，再次给网卡中断绑核，不会变成随机处理中断了。
ps -ef | grep irqbalance
检查中断号对应的 CPU 亲和
检查网卡队列绑核，没有发现明显异常：
尝试其他绑核方式
由于机器有 4 个 NUMA 节点，将网卡队列中断绑核方式调整为每个 NUMA 节点 4 核，对应的例如：
29-31,61-63,93-95,125-127
但实际测试后，发现用于网络中断的 12 个核心，使用率仍然是不平衡的状态。
尝试调整队列数量:核心数量为 2:1
绑核方式就是本文解决方案里的内容。
实际测试后，发现网络中断处理的 CPU 使用率居然比较平衡了。
不过这种绑核方式的缺陷也显而易见：网卡的 32 队列，实际上只能利用大约 16 个 CPU 核心。