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

文章描述了一次在泰山服务器上进行性能测试时遇到的问题,即应用进程CPU使用率低于预期。问题根源在于网卡绑核方式不当,导致中断处理不均衡。通过检查irqbalance进程、调整网卡队列与CPU核心的绑定方式,最终发现每2个队列绑定1个CPU核心能有效平衡软中断CPU使用率,从而改善了应用程序的性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前言

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

wuweijie@apache.org

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值