泰山服务器板载 HNS3 网卡绑核无法充分利用 CPU 的解决思路

前言

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