文章目录
- 前言
- 解决方案
- 排查过程
- 应用程序运行环境与方式
- 检查是否存在 irqbalance 进程
- 检查中断号对应的 CPU 亲和
- 尝试其他绑核方式
- 尝试调整队列数量:核心数量为 2:1
前言
前段时间在泰山服务器上进行性能测试,预期是应用进程能够占满机器大部分 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 核心。