搞过RDMA网络的兄弟们都知道，网络建完只是万里长征第一步。真正让人头疼的，是后面的测试、排错和监控。这玩意儿可不像传统网络那样，ping通了就算完事。RDMA这东西，性能敏感得要命，稍微有点问题就能让你的应用性能从云端掉到地板上。

今天就跟大家聊聊，RDMA网络上线后到底该怎么折腾，怎么确保这套系统真的能扛得住生产环境的摧残。

测试阶段：别被表面现象骗了

基础连通性测试 - 这只是开胃菜

首先得确认RDMA设备能不能正常工作。别小看这一步，很多时候问题就出在这里。

 # 检查RDMA设备状态
 ibv_devices
 ibv_devinfo
 
 # 查看端口状态
 ibstat

如果这些命令跑不出来或者显示异常，那后面就不用测了。但是，这些都正常也不代表万事大吉。

性能基准测试 - 这才是重头戏

RDMA网络的核心价值就是性能，所以性能测试必须要做得彻底。我推荐用ib_send_bw、ib_read_bw这些工具，但是得有技巧：

带宽测试的套路：

 # 服务端
 ib_send_bw -d mlx5_0 -i 1 -s 65536 -n 100000
 
 # 客户端
 ib_send_bw -d mlx5_0 -i 1 -s 65536 -n 100000 <server_ip>

这里有几个坑要注意：

• 消息大小要测试多个档位，从4KB到64KB都要试
• 测试时间要足够长，短时间测试看不出问题
• 要在不同负载情况下测试，空闲时能跑满带宽没用，关键是有其他业务时还能不能保持

延迟测试更关键：

 ib_send_lat -d mlx5_0 -i 1 -s 64 -n 100000

延迟测试要特别关注P99延迟，不是平均延迟。很多时候平均延迟看起来很美好，但是P99延迟高得离谱，这对实时应用来说就是灾难。

稳定性测试 - 最容易被忽略的环节

这个环节经常被跳过，但其实最重要。生产环境不是实验室，各种异常情况都可能发生。

我一般会让测试跑24小时以上，期间要模拟各种故障场景。这不是在虐待设备，而是在救你的命。生产环境出问题的成本，比测试环境高几个数量级。

排错技巧：从入门到放弃再到精通

性能问题排查 - 最常见也最头疼

RDMA性能问题的排查，需要从多个角度入手：

1. 硬件层面检查

 # 检查网卡状态
 ethtool -S eth0 | grep -i error
 # 检查PCIe链路
 lspci -vvv | grep -A 20 Mellanox

PCIe带宽不够是个常见问题。100Gb RDMA网卡需要PCIe 3.0 x16或者PCIe 4.0 x8才能跑满。很多服务器的PCIe配置不合理，这个得提前确认。

2. 驱动和固件

 # 检查驱动版本
 modinfo mlx5_core
 # 检查固件版本
 mstflint -d /dev/mst/mt4119_pciconf0 q

驱动和固件版本匹配问题能让你怀疑人生。我见过因为驱动版本不对，性能只能发挥一半的情况。

3. CPU和内存 RDMA对CPU和内存的要求也很高。CPU核心数不够、内存带宽不足、NUMA配置不当，都会影响性能。

 # 检查NUMA配置
 numactl --hardware
 # 检查CPU亲和性
 taskset -c 0-15 your_rdma_app

连接问题排查 - 简单粗暴但有效

连接问题相对好排查，但也有一些技巧：

 # 检查IB子网
 ibnetdiscover
 # 检查路由
 ibroute
 # 检查交换机状态
 ibswitches

如果是RoCE，还要检查以太网层面的配置：

 # 检查流控
 ethtool -a eth0
 # 检查VLAN配置
 ip link show

应用层问题 - 最难定位的

应用层问题最难搞，因为涉及到具体的业务逻辑。但有几个通用的排查方法：

内存注册问题： RDMA需要预先注册内存，这个过程很耗时。如果应用频繁注册/注销内存，性能会很差。

队列深度配置： 发送队列和接收队列的深度要合理配置。太小会限制性能，太大会浪费内存。

轮询vs事件驱动： 轮询模式性能更好但占用CPU，事件驱动模式CPU占用低但延迟高。要根据具体应用选择。

监控系统：不是可选项，是必需品

基础监控指标

RDMA网络的监控不能只看带宽利用率，还要关注很多其他指标：

告警策略

告警不是越多越好，要有重点。我一般会设置这些告警：

高优先级告警：

• 端口down
• 错误率超过阈值
• 延迟异常波动

中优先级告警：

• 带宽利用率过高
• 温度过高
• 连接数异常

低优先级告警：

• 性能轻微下降
• 配置变更

监控工具选择

开源的话推荐Prometheus + Grafana，商业的话Mellanox的NEO不错。但不管用什么工具，关键是要能及时发现问题。

我自己写过一个简单的监控脚本：

 #!/bin/bash
 # 简单的RDMA监控脚本
 while true; do
     # 检查端口状态
     ibstat | grep -E "State|Physical"
     
     # 检查错误计数
     ibv_devinfo | grep -A 5 "port_rcv_errors"
     
     # 检查性能
     ib_send_bw -d mlx5_0 -D 1 -F --report_gbits
     
     sleep 60
 done

性能基线很重要

建立性能基线是监控的基础。没有基线，你就不知道什么是正常，什么是异常。

我建议在系统上线初期，每天都要记录关键指标，建立一个性能基线库。这样后面出问题时，就能快速判断是哪个环节出了问题。

一些踩过的坑

网卡固件bug

遇到过一个奇葩问题，网卡在特定的消息大小下会出现性能急剧下降。最后发现是固件bug，升级固件解决了。所以固件版本很重要，但也不能盲目升级，要看release notes。

交换机配置不当

RoCE对交换机的要求很高，PFC（优先级流控）配置不当会导致性能问题。很多网管对这个不熟悉，结果RDMA网络跑得像蜗牛一样。

应用层缓存问题

见过应用层缓存策略不当，导致RDMA性能发挥不出来的情况。RDMA的零拷贝特性需要应用层配合，不是说换个网卡就能自动提升性能。

总结

RDMA网络的测试、排错和监控，是一个系统工程。不能指望一蹴而就，需要持续的投入和优化。

最重要的是要建立完善的监控体系，这样才能及时发现问题、快速定位问题、有效解决问题。

记住，RDMA网络的价值不在于部署完成，而在于稳定可靠地运行。测试、排错、监控这些"脏活累活"，才是真正决定RDMA网络成败的关键。

别被厂商的PPT忽悠了，真正的挑战在生产环境里。做好这些基础工作，才能让RDMA网络真正发挥价值。

#ai# #头条创作挑战赛# #算力# #智算中心#