AI 集群 技术知识库

Appearance

故障排查 ​

在执行mccl bench测试中，如发现性能不及预期的情况，先保证测试环境已按照该文档上述章节进行了正确的环境配置，然后进行如下排查，如仍有问题，可联系通信库团队协助定位。

系统环境排查 ​

1、确认集群各机器没有GPU卡和网卡掉卡的情况，安装的maca软件栈、vbios的版本是一致的，机器没有在并行跑其他程序。

2、运行账户权限问题，要确保当前账号已加入video组，或者使用sudo权限运行（不推荐）。

未加video组，通常会报如下图中的初始化失败错误，通过命令usermod -aG video current_user_name添加；添加用户组后，需注销重新登录才会生效。

系统环境排查

3、确保GPU P2P链路通信是正常的，P2P通信测试正常运行。

如果单机通信测试多次不达标，则可能是Metaxlink/PCIe掉速的问题，判断MetaxLink/PCIE掉速的最直接的方式，是运行上述7.2章节的P2P测试，如果发现有异常低值，则可判断出哪些GPU间的物理链接发生掉速。

掉速的解决方法，首先可以BMC重启机器，如无效则需要关机重新插拔或者更换Metaxlink桥接板。

另有如下判断方式：

注意：C500有低功耗模式，MetaxLink/PCIe在空闲时显示2.5GT/s，在GPU工作时可恢复至标准速度，这是正常现象，在查看速度时需要跑一些测试程序，激活带宽。

MetaxLink掉速判断方法 ​

1、最直接的方式是运行P2P测试，根据测试矩阵结果的差异性来判断某些GPU间的Link是否掉速。

2、通过查看系统属性值来判断，在DPM模式下需激活。

在操作系统中执行命令：mx-smi topo --show-mxlk

对于C500 工作状态下 speed 必须是32GT/s，否则就是掉速。

width必须是x16，否则就是掉速。(dragonfly 机器有部分为x8；C600系列为x8)

如图为metaxlink掉速，需要进行硬件重插拔、更换等操作。

MetaxLink掉速判断方法

MetaxLink高并发下掉速判断方法 ​

1、某些场景下p2p的打流都是正常的，但是跑业务性能不达预期，可以通过mx-smi mxlk --show-bandwidth查看实时的metaxlink上的带宽

MetaxLink高并发下掉速判断方法

2、如果发现了metaxlink上的带宽没有被打满，可以通过tranferbench的alltoall测试来定位，测试方法参考P2P单机测试，需要修改点为第3步 p2p.sh脚本中最后启动参数p2p改为a2a，运行p2p.sh脚本，即会并发测试所有metaxlink的连接带宽。判断是否达到理论值，就可以判断是否掉速。

MetaxLink高并发下掉速判断方法

PCIe掉速判断方法 ​

PCIe掉速定位，有可能是gpu的PCIe掉速，也有可能是上行链路的PCIe switch掉速。

  • mx-smi --show-pcie 查看gpu的PCIe是否掉速

注意观察参数，对于C500 Max Width和Current Width必须是x16，否则就是掉速。

根据PCIe switch的型号不同，有的机器Max Speed为32GT/s，有的是16GT/s，但是在GPU工作时，Max Speed 一定会和Current Speed相等，否则就是掉速。

PCIe掉速判断方法

  • 查看PCIe 拓扑结构 lspci -tv

可知gpu 0000:08:00.0的上行链路为0000:04:00.0

PCIe掉速判断方法

  • 查看PCIe上行链路的带宽信息：
bash
sudo lspci -s 0000:08:00.0 -vvv | grep -E "LnkCap|LnkSta:"
sudo lspci -s 0000:04:00.0 -vvv | grep -E "LnkCap|LnkSta:"

PCIe掉速判断方法

根据服务器型号不同，结果应为32GT/或者16GT/s，width: x16，否则就是掉速。

掉速后需要进行硬件重插拔、更换等操作。

网络问题 ​

硬件问题 ​

1、检查网卡和交换机的连线是正确的，服务器网卡端和交换机的指示灯都是点亮状态。

2、运行命令ibstat，确认ib网卡处于Active状态。

3、使用ib_write_bw带宽测试工具打流，细分定位是不是网卡掉速。

软件问题 ​

在排除网络硬件问题以后，若通信仍然异常，则应该重点排查软件问题。

peer_mem机制不可用 ​

由于技术演进，在高版本linux内核的IB-core子系统中移除了对peer_mem机制的支持，进而导致RDMA通信异常。

对于上述这种限制，有两种方法进行确认。

1、读取内核属性文件 /sys/class/mxcd/mxcd/layout/properties 或者 /sys/class/metax/mxcd/layout/properties，比如

peer_mem机制不可用

当属性字段peer_mem的值为0时，即表示metax模块在默认加载方式不支持peer_mem机制来注册MR.

2、使用ib_write_bw进行双机ib打流测试，若出现下图所示错误输出，则也表示peer_mem机制不可用。

peer_mem机制不可用

当遇上peer_mem机制不可用时，推荐参考 8.5.7 节通过使能dmabuf来支持RDMA网卡的GDR功能。

除此以外，也可以使用下面给出的兼容方案：指定ib_reg_addr，ib_unreg_addr的地址，重新加载metax模块，以恢复peer_mem注册机制。

sudo rmmod metax

sudo cat /proc/kallsyms |grep peer_memory_client

ffff8000015f7074 T ib_register_peer_memory_client
ffff8000015f7274 T ib_unregister_peer_memory_client

sudo modprobe metax ib_reg_addr=0xffff8000015f7074  ib_unreg_addr=0xffff8000015f7274

peer_mem机制不可用

以root用户执行如下脚本方式：

#!/bin/bash
rmmod metax
ib_register_peer=$(cat /proc/kallsyms |grep "T ib_register_peer_memory_client" | awk '{print $1}')
ib_unregister_peer=$(cat /proc/kallsyms | grep "T ib_unregister_peer_memory_client" | awk '{print $1}')

ib_reg_addr="0x${ib_register_peer}"
ib_unreg_addr="0x${ib_unregister_peer}"

modprobe metax ib_reg_addr=${ib_reg_addr} ib_unreg_addr=${ib_unreg_addr}

CPU问题 ​

目前所有的OAM服务器（浪潮、立讯、新华三等）及所有类型的浪潮服务器在默认的节能模式（powersave）下，通信库测试会出现单机多卡和多机多卡时延显著增大，及性能不稳定的情况（一部分和中断处理性能相关），需将CPU的模式设置为性能模式（performance）。

查看模式命令：cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

设置模式命令：echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

该配置在重启服务器后会失效，可配置为重启默认开启。

PCIe配置问题 ​

1、ACS问题。MetaxLink互联的GPU间的P2P测试性能达标，但是mccl test perf测试不达标或者直接卡住，需要检查是否设置了PCIe ACS，具体步骤参见第2章。

如开启了ACS，会导致PCIe P2P性能下降，目前多卡互联通信，复用了MetaxLink和PCIe并发通信，PCIe性能下降会拖慢多卡整体性能，甚至慢到卡住，此时需要使用环境变量MCCL_PCIE_BUFFER_MODE=0来关闭MCCL中的PCIe链路。目前虚拟化场景会强制设置PCIe ACS。

2、PCIe硬件拓扑问题。有些服务器的4卡GPU并不是统一连接在同一PCIe Switch下，会导致PCIe链路降速，可以通过lspci -tvvv来判断，此种情况也需要使用环境变量MCCL_PCIE_BUFFER_MODE=0来关闭MCCL中的PCIe链路，或者修改硬件拓扑，将4张GPU连接到同一PCIe Switch下。

系统资源问题 ​

集群中某些系统资源不够，可能会导致集群测试跑不起来，尤其是百卡以上的all to all perf，此时需要修改系统资源上限值。

可以使用命令ulimit -a查看系统目前的相关资源上限值，如下

系统资源问题

报错Too many opened files，是由于同一时刻系统打开的文件数量超过允许打开的上限值open files，需要修改系统文件来解决。

系统资源问题

解决办法：

  • 打开/etc/security/limits.conf，在最后一行增加如下四行，数字尽量设置的大点。
* soft nofile 409600
* hard nofile 409600
root soft nofile 409600
root hard nofile 409600
  • 打开文件/etc/profile，在最后一行增加如下内容，数字和/etc/security/limits.conf设置的数字保持一致。
ulimit -SHn 409600
  • 打开文件/etc/rc.local，在最后一行增加如下内容，数字和/etc/security/limits.conf设置的数字保持一致。
ulimit -SHn 409600
  • 如果是docker，请在docker里面修改配置，或者在docker run时使用--ulimit参数修改docker的限制。
--ulimit nofile=409600:409600

上述a/b/c三步配置完后，无需重启机器即可生效，再次使用B查看open files这一行，可以发现数值变成了自己设置的数字。

VSwitch问题 ​

多卡通信性能不达标，注意是否是vswitch影响。

如执行/opt/maca/sample/mccl_tests/perf/cluster.sh脚本跑多机all2all测试时，发现all2all性能低于正常值，可以排查下是否是vswitch的影响。

比如汇天集群上，两台C550机器192.168.8.1和192.168.8.3 两机16卡alltoall正常性能如图一，

VSwitch问题

但是发现两台C550机器192.168.8.1和192.168.9.27 两机16卡的all2all性能只有正常值的一半，如图，

VSwitch问题

此种情况很可能是vswitch的影响，需要手动执行脚本/opt/maca/tools/mccl/kit/virtualPcieSwitchDetect/virtualSwitchDetect.sh文件，执行完毕后会重新生成vswitch相关文件到/opt/pci_switch_links。

在docker中也需要执行该脚本，或者制作docker时将物理机上的/opt/pci_switch_links映射到容器中。

多机测试报错 ​

遇到多机或者集群环境运行通信库测试报错（测试出错、卡住或者数据校验错误），可以安排以下步骤排查。

1、保证每台机器单机状态是正常的；

2、多机间账户免密访问已配置；

3、确保网卡、交换机网络通路状态正常，可以使用ib perf来逐一测试每台机器的每张网卡状态，详见网卡测试章节；如果数据校验出错问题，可添加--data_check参数进行检测；

4、多机mccl perf测试要确保测试脚本的正确性，详见MCCL多机测试章节；要注意MCCL_IB_GID_INDEX和MCCL_IB_HCA等网络环境变量设置的正确性；

5、如果多机测试有问题，可能是某台机器状态不正常，可以采用二分法逐步减少机器，直至筛选出有问题的机器；或者从2台机器开始，逐步添加机器进行测试；

6、如已确认某台机器有问题，可进一步通过不同的GPU和网卡组合测试，来确定哪个GPU或网卡有问题。

7、在多机环境遇到模型出错或者性能问题，尤其要排查每个机器的MACA软件版本是否一致，网卡驱动和FW版本是否一致，网卡配置（如MRRS）是否合理且一致，交换机配置是否最优。