RDMA网络配置相关的性能问题总结

注：本文内容引用自张洋老师的知乎文章 https://zhuanlan.zhihu.com/p/717483769，他是一位存储研发专家。

在IB/RoCE网络环境中，经常会遇到一些网络相关的配置不当问题，这些问题可能导致性能出现降级。本文对这些问题做一个总结，以供记录备忘。

网卡降级

网卡降级会明显导致读写带宽测试时带宽打不满网卡上限。例如，有两张100G的IB卡，那么读带宽测试应该达到22GB/s以上的带宽。如果出现一张卡降级，两张卡的带宽表现大概在17GB/s左右；如果出现两张卡同时降级，两张卡的带宽表现在12GB/s左右。出现上述带宽不符合预期的情况时，便可以检查是否有网卡降级的情况。

通过执行命令 lspci | grep Mell，可以发现有两张迈洛斯的IB网卡。其中一张的PCI地址为 17:00.0，另一张的PCI地址为 ca:00.0。

[root@host05 perf_test]# lspci | grep Mell
17:00.0 Infiniband controller: Mellanox Technologies MT27800 Family [ConnectX-5]
ca:00.0 Infiniband controller: Mellanox Technologies MT27800 Family [ConnectX-5]

注：上面部分可按住屏幕左右拖动，以下同

然后，通过执行命令 lspci -vvs 17:00.0 查看该PCI地址的详细信息。在这里，我们关注是否有降级的情况。

[root@host05 perf_test]# lspci -vvs 17:00.0 | grep -E "LnkSta:|LnkCap:"
                 LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM not supported
                 LnkSta: Speed 8GT/s (ok), Width x16 (ok)

这个信息看起来是正常的，没有降级的情况，符合预期。反之，会出现“downgraded”的标识。在排查性能问题的过程中，我们首先应该检查硬件环境是否符合预期，否则可能会浪费不少时间。

网络拓扑问题

以 zStorage 为例，典型的 3 节点网络拓扑结构如下：

如图的拓扑图中，包含 1 个计算节点（HOST），3 个存储节点以及两台 IB 交换机。然后，每个计算节点和存储节点分别安装有两张 IB 卡。这样的组网方式保证了任何一个组件故障，都不会影响集群的可用性。

这里注意看，两个交换机之间有两根连线，这样可以保证不同网段的 IB 卡可以正常通信。在 zStorage 中，所有组件状态正常情况下，不会使用到网段间的交叉连接。仅当 IB 卡故障，只剩下交叉连接可以通信时，才会用到交叉连接。

当网络配置错误，例如网络连线插错，可能出现在正常情况下，也使用了交换机中间连线的情况。由于交换机中间连线成为瓶颈，性能测试表现为带宽达不到预期，例如：预期为 22GB/s，实际只能到 17GB/s。

通过 ibstat 可以查看 IB 卡的信息，如图，左边显示的是一个存储节点的信息，右边显示的是另一个存储节点的信息。

然后，通过执行 ibtracert 命令，可以查看两张网卡之间经过了几个交换机。

[root@cell02 ~]# ibtracert 640 592
 From ca {0x1070fd0300631480} portnum 1 lid 640-655 "cell02 mlx5_0"
 [1] -> switch port {0x08c0eb03000e9de0}[6] lid 1-1 "MF0;switch25:MSB7800/U1"
 [3] -> ca port {0x1070fd030065537a}[1] lid 592-607 "cell03 mlx5_0"
 To ca {0x1070fd030065537a} portnum 1 lid 592-607 "cell03 mlx5_0"

如上，ibtracert 的参数中，640 是第一个存储节点第一张卡 mlx5_0 的 base lid，592 是第二个存储节点第一张卡 mlx5_0 的 base lid。可见，这两张卡是通过 switch25 相连的，符合预期。

再试试使用 base lid 640 到存储节点 2 的第二张卡 base lid 48。可见，它经过了 switch25 和 switch-ib14 两个交换机，因为这两张卡连接到了不同的网段，这也符合预期。

[root@cell02 ~]# ibtracert 640 48
 From ca {0x1070fd0300631480} portnum 1 lid 640-655 "cell02 mlx5_0"
 [1] -> switch port {0x08c0eb03000e9de0}[6] lid 1-1 "MF0;switch25:MSB7800/U1"
 [27] -> switch port {0x248a070300ecdec0}[25] lid 3-3 "MF0;switch-ib14:MSB7800/U1"
 [2] -> ca port {0x043f720300da2610}[1] lid 48-63 "cell03 mlx5_1"
 To ca {0x043f720300da2610} portnum 1 lid 48-63 "cell03 mlx5_1"

反之，如果 ibtracert 640 592 显示的信息表明经过了两个交换机，那么可以说明网络连接不正确，需要调整。因为这两张卡属于同一个网段，它们应该只经过一个交换机。

无损网络配置问题

IB 网络下，默认是无损网络，不需要单独配置。但是在 RoCE 下，需要单独配置 PFC/ECN 这样的功能来实现无损网络。

当多个压力节点模拟网络负载发送到同一个目标节点时，目标节点对应的交换机端口可能会出现拥塞，从而导致丢包现象。然后，发送端会重传数据。如此丢包重传便会导致性能波动下降，达不到预期。这种丢包的情况，可以理解为“有损”。

在 zStorage 测试 IO 带宽性能时，通常表现为：1）带宽的波动；2）增加并发后，带宽降低，波动加剧；3）交换机统计到丢包严重。

RoCE 实际上通过传统的以太网上实现 RDMA 协议，而以太网上存在如上的丢包问题。一些高端的交换机支持 PFC/ECN 功能，通过配置该功能可以实现“无损”网络。各个品牌交换机的配置方式大致相同，但又略有差异，本文不详解。

通过 PFC/ECN 实现的无损网络，在实际测试时效果还是相当好的，且相比于 IB 交换机，性价比很高。

网卡软中断CPU争用问题

这个问题是在 zStorage 测试融合部署模式下发现的。具体表现为：将存储节点作为计算节点提供块设备服务时，使用 fio 工具下发 IO 负载，会出现性能波动严重，性能数据不符合预期的情况。即使将 fio 绑定到空闲的 CPU 核心上，问题依然存在。

通过 top 命令，按 1 显示各个 CPU 核心的详细情况，可见 si（软中断）一列占用 CPU 很高，且与 zStorage 的进程抢占 CPU。操作系统不会将软中断调度到空闲的 CPU 核心上去。

所以，需要手动（或脚本化）地将网卡产生的中断绑定到其他空闲的 CPU 核心上。可以通过 /proc/interrupts 中的信息观察哪个中断号产生的中断最多。通过一个自己实现的脚本分析结果如下：例如，第一行显示，14 号 CPU 上，246 号中断，在 5 秒内增加了 337210 次。通过命令 echo 20 > /proc/irq/252/smp_affinity_list，将 252 号中断绑定到 CPU 20 上去处理。

以下是脚本化的效果：通过自动化脚本，我们成功地将中断绑定到了空闲的 CPU 核心上，显著降低了软中断对 CPU 的争用问题。

通过将软中断迁移到其他空闲核心后，性能测试数据恢复正常，达到了预期。

网卡时延问题

最后，这个问题是在测试 Intel IB 网卡时出现的一个问题：IO 时延始终大于 1ms，即使是在测试 4K 单并发 IO 时，预期应该小于 100us。通过时延点位分析，发现导致时延异常的范围是计算节点，问题并非由存储节点导致。

中间分析问题的过程比较曲折，这里不详述。最后，通过更换 Linux 内核解决了问题。

其他

其他还有一些通过设置系统参数的优化方法，例如设置 MTU 大小等。由于在我们的环境中，这类参数的影响较小，因此不作详述。

作者

“云和恩墨 zStorage 分布式存储团队” 张洋

扩展阅读：《企业存储技术》文章分类索引（微信公众号专辑）》

注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎在留言中批评指正。如果您想在这个公众号上分享自己的技术干货，也欢迎联系我：）

感谢您的阅读和支持！《企业存储技术》微信公众号：HL_Storage

长按二维码可直接识别关注

历史文章汇总：http://www.toutiao.com/c/user/5821930387/

http://www.zhihu.com/column/huangliang