前言

前段时间在泰山服务器上进行性能测试，预期是应用进程能够占满机器大部分 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。

ps -ef | grep irqbalance

检查中断号对应的 CPU 亲和

检查网卡队列绑核，没有发现明显异常：

尝试其他绑核方式

由于机器有 4 个 NUMA 节点，将网卡队列中断绑核方式调整为每个 NUMA 节点 4 核，对应的例如：

29-31,61-63,93-95,125-127

但实际测试后，发现用于网络中断的 12 个核心，使用率仍然是不平衡的状态。

尝试调整队列数量:核心数量为 2:1

绑核方式就是本文解决方案里的内容。
实际测试后，发现网络中断处理的 CPU 使用率居然比较平衡了。
不过这种绑核方式的缺陷也显而易见：网卡的 32 队列，实际上只能利用大约 16 个 CPU 核心。