181、RDMA性能基准测试：设计科学的测试方案

一次让我失眠的半夜调试

凌晨两点，数据中心告警。新上线的RDMA存储集群，理论带宽100Gbps，实测只有37Gbps。业务方在群里@我，老板在飞书问进度。我盯着perftest的输出，心跳和那个可怜的带宽数字一样低。

更诡异的是——同样的硬件，同样的驱动版本，隔壁团队的测试报告写着92Gbps。他们用的是perftest默认参数，我们也是。问题出在哪？

折腾到凌晨四点，终于发现：我们的测试机插在ToR交换机的不同端口上，一个端口开启了PFC流控，另一个没有。更致命的是，测试脚本里忘了设置CPU亲和性，中断全部打到了Numa远端核心。

那次之后，我给自己定了个规矩：RDMA性能测试，不是跑个perftest就完事。测试方案本身，就是系统的一部分。

测试前的环境检查清单

硬件拓扑确认

别急着跑测试。先搞清楚你的硬件长什么样：

# 查看网卡PCIe信息，确认链路宽度和速率
lspci -vvv -s 03:00.0 | grep -E "LnkSta|LnkCap"
# 输出示例：LnkSta: Speed 16GT/s, Width x16
# 这里踩过坑：x8的PCIe 3.0理论带宽只有64Gbps，跑100Gbps网卡就是扯淡

检查Numa拓扑：

# 确认网卡所在Numa节点
cat /sys/class/infiniband/mlx5_0/device/numa_node
# 确认CPU核心分布
lscpu | grep "NUMA node"

别这样写：直接跑测试，然后发现带宽上不去，回头查PCIe链路是x8。这种低级错误我犯过三次。

固件与驱动版本

# 查看固件版本
ibstat | grep "Firmware"
# 查看驱动版本
modinfo mlx5_core | grep version
# 确认是否匹配厂商推荐组合
# 这里踩过坑：ConnectX-5固件版本16.27.1000搭配驱动5.0-2，带宽死活跑不满
# 升级到16.32.1010 + 5.4-3，问题解决

系统参数调优

# 关键参数，少一个都不行
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"

# 大页配置
echo 1024 > /proc/sys/vm/nr_hugepages
# 别这样写：不配大页直接跑，内存分配延迟会吃掉20%性能

测试工具的选择与陷阱

perftest：最常用也最容易误用

perftest是Mellanox官方工具集，包含ib_write_bw、ib_read_bw、ib_send_bw等。但默认参数坑很多：

# 错误示范：直接跑
ib_write_bw -d mlx5_0

# 正确姿势：明确指定参数
ib_write_bw -d mlx5_0 -p 18515 –report_gbits -F –run_infinitely \\
–duration=60 –cpu_util –use_hugepages=1 \\
–inline_size=64 –mtu=4096 –tx_depth=128 –rx_depth=128

参数说明（踩坑经验）：

• –report_gbits：输出单位是Gbps，不是MB/s。别搞混
• –duration=60：至少跑60秒。30秒不够，冷启动阶段数据不稳定
• –use_hugepages=1：必须开。不开大页，带宽掉20%
• –inline_size=64：小消息场景有用。大消息场景设0反而更好
• –tx_depth=128：发送队列深度。太浅（如8）会饿死流水线，太深（如512）可能触发拥塞

多线程测试的坑

# 多线程测试，注意CPU亲和性
ib_write_bw -d mlx5_0 –report_gbits –run_infinitely \\
–duration=60 –use_hugepages=1 \\
–num_of_qps=8 –num_of_threads=8 \\
–cpu_binding=0-7 # 绑定到网卡所在Numa的核心

这里踩过坑：8个线程没绑核，全部跑到Numa远端，带宽从90Gbps掉到45Gbps。用taskset或numactl绑核是必须的。

消息大小的选择

# 测试不同消息大小的性能
for size in 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576; do
ib_write_bw -d mlx5_0 –report_gbits –duration=30 \\
–use_hugepages=1 –inline_size=64 \\
–size=$size
done

经验数据（ConnectX-5，100Gbps）：

• 64字节以下：延迟主导，带宽<10Gbps
• 256字节-4KB：带宽开始爬升，约30-60Gbps
• 16KB以上：接近线速，>90Gbps
• 1MB以上：可能触发内存带宽瓶颈，反而下降

测试场景设计

单流 vs 多流

# 单流测试：验证单连接极限
ib_write_bw -d mlx5_0 –report_gbits –duration=60 –use_hugepages=1

# 多流测试：模拟真实多连接场景
ib_write_bw -d mlx5_0 –report_gbits –duration=60 –use_hugepages=1 \\
–num_of_qps=16 –num_of_threads=16

别这样写：只测单流，然后宣称系统性能。真实业务场景通常是多流并发，单流数据只能作为上限参考。

双向测试

# 双向同时读写
ib_write_bw -d mlx5_0 –report_gbits –duration=60 –use_hugepages=1 \\
–bidirectional

双向测试能暴露PCIe带宽瓶颈。有些网卡单方向能跑满，双向就掉到60%。

延迟测试

# 延迟测试，注意要跑足够多次
ib_write_lat -d mlx5_0 –duration=30 –use_hugepages=1 \\
–size=64 –iters=1000000

这里踩过坑：–iters设太小（如10000），延迟抖动大，数据不可信。至少100万次迭代。

数据采集与分析方法

实时监控

# 测试期间监控网卡统计
watch -n 1 "ethtool -S mlx5_0 | grep -E 'rx_bytes|tx_bytes|rx_packets|tx_packets'"

# 监控PCIe错误
watch -n 1 "cat /sys/kernel/debug/mlx5/0000:03:00.0/pcie_err_counters"

结果记录模板

每次测试必须记录以下信息：

测试日期：2024-01-15
测试人员：张三
硬件信息：
– 网卡：ConnectX-5 100Gbps
– PCIe：Gen3 x16
– CPU：Intel Xeon Gold 6248
– 内存：256GB DDR4 2933
软件信息：
– 驱动：mlx5_core 5.4-3
– 固件：16.32.1010
– 内核：5.10.0-28
– OFED：5.4-3.0.3.0
测试参数：
– 工具：ib_write_bw
– 消息大小：64B, 256B, 1KB, 4KB, 16KB, 64KB, 1MB
– 队列深度：128
– 线程数：1, 4, 8, 16
– 持续时间：60s
– 大页：启用
– CPU绑定：Numa node 0, cores 0-15
结果：
– 64B: 2.3Gbps, 1.2us延迟
– 4KB: 45.6Gbps
– 64KB: 92.1Gbps
– 1MB: 88.7Gbps
备注：
– 双向测试带宽下降至78Gbps，怀疑PCIe带宽瓶颈

常见问题排查

带宽上不去

延迟抖动大

多线程性能不线性

个人经验总结

最后说一句：测试方案设计得好，能省掉80%的排查时间。别急着跑数据，先把方案想清楚。

关键词

核心关键词：RDMA、带宽、PCIe、NUMA、中断、MB、perftest、内存带宽、双向测试、并发

精准长尾关键词：RDMA性能基准测试、设计科学的测试方案、硬件拓扑确认、固件与驱动版本、系统参数调优、测试工具的选择与陷阱、RDMA性能基准测试详解、RDMA性能基准测试实战、设计科学的测试方案排查、RDMA编程实战、RDMA性能优化、RDMA协议详解