昇腾集群PFC现象分析

一、PFC产生原因

负责集群运维的同学可能都遇到过PFC现象，那么PFC到底是啥？产生原因是什么？这篇文章提供了一些分析。

首先，参考官网文档的说法：

PFC（Priority-based Flow Control）的含义是基于优先级的流量控制，它是目前应用最广泛的能够有效避免丢包的流量控制技术，是智能无损网络的基础。使能了PFC功能的队列，我们称之为无损队列。当下游设备的无损队列发生拥塞时，下游设备会通知上游设备会停止发送该队列的流量，从而实现零丢包传输。

我们来通过一个例子来理解一下。如下图所示，图中画出了一个昇腾集群中的部分AI服务器和交换机（switch），交换机的作用是实现不同服务器之间的通信（大多是在分布式训练任务中）。比如说server 1、server 2和server 3可以通过switch 1进行通信，server 2和server 3可以通过switch 2进行通信。每个switch的收、发带宽都是固定的，而且都有一定的缓存空间。为啥需要缓存呢？因为有可能多个server同时发送流量过来，但是这些流量之和超过了switch的带宽，所以需要先放行部分流量，然后缓存剩下的。而且为了防止缓存超载，要设置一个水线，缓存超过这个水线，就会报警了，也就会触发下面所说的PFC现象了。

AI集群示例

现在假设switch 1 的入口带宽为1.5M，缓存空间为1.5M，缓存水线为1M。假如某一时刻，server 1、server 2同时向switch 1 发送数据，server 1的数据大小为1.3M，server 2发送的数据大小为1.2M，那么switch 1可以让server 1或者server 2 的数据先通过（例如server 1先过），然后缓存另一个。由于缓存的数据大小超过了switch 1的水线，所以此时switch 1会向server 2发送一个反压信号，告诉server 2不要再发数据来啦！但是当switch 1的缓存数据低于水线之后，它又会给server 2发个消息说：我OK啦，可以发消息啦！

所以说，反压信号包含2类，一类是stop，一类是continue。

同理，服务器侧的NPU也会有PFC信号，因为NPU可能会同时接收多个switch发送过来的消息。

二、PFC原因排查

出现PFC现象后，会有两种结果，一种是对集群的性能产生了影响，甚至导致集群不可用；还有一种情况就是对性能没有影响。

我们先讨论后一种情况，这种情况很可能是并行通信过程中常见的“多打一”场景，也就是服务器同时收到多个交换机发送的数据或者交换机同时收到多个服务器发送过来的消息。我们可以利用mindstudio insight来判断是否存在这种情况，下面通过一个例子来解释。

假如我们现在有一份多机多卡的profiling，我们使用mindstudio insight把它加载进来，然后查看timeline和“通信”子界面的通信算子的时序，从而判断是否有“多打一”的情况。

2.1 服务器侧NPU可能出现PFC的场景

NPU侧出现“多打一”，是因为同时收到了多个交换机发送过来的数据，所以我们可以观察每个卡的HCCL timeline，看看是否有多个跨机通信域的通信算子同时执行。注意，这里强调“跨机”是因为只有跨机的通信才会用到交换机。跨机通信域一般包括pipeline并行、数据并行等，具体哪些通信域是跨机的，还需要根据实际的并行配置进行判断。

Mindstudio insight timeline

如上图所示，红框截图就是1号卡的通信域的算子执行时序，每个卡有多个通信域，因为这个卡可能同时参与了多种并行，蓝框的每个plane反馈的也是通信行为，只是它反馈的是task粒度，Group xx communication 反馈的是算子粒度。我们点击绿框中的标记就可以把这一行置顶。所以我们可以把1号卡的多个跨机通信域的算子执行序置顶，这样就可以看到哪些算子存在并发行为。那么有同学问了，我怎么知道哪些 communication group是跨机通信域呢？1，版本开发的同学正在做一个需求，就是显示每个communication group对应哪些卡，这样我们就可以知道是不是跨机通信域了，比如说4机32卡的集群，[0, 8, 16, 24]组成的一个通信域就是跨机的（0号卡属于1号服务器，8卡属于2号服务器，16卡属于3号服务器，24卡属于4号服务器）；2，在这个需求做出来之前，我们可以通过分析这个group里面的通信算子类别判断它对应的是什么通信域：）。

置顶后的通信域算子执行时序

上图是把1号卡的不同通信域算子执行序置顶后的结果，我们可以把时间轴拉开，看看不同的跨机通信域的通信算子（reveice过程）是否存在并发状态，如果有，那么很可能会导致服务器侧出现PFC现象！

2.2 交换机可能出现PFC的场景

交换机出现“多打一”，是因为同时有多个跨机通信行为使用了同一个交换机进行数据交换。有2种情况会导致这种行为发生，一种是上面举例的[0, 8, 16, 24]组成的通信域中，多个卡同时向同一个交换机发送数据；另一种是多个跨机通信域中的多个卡，同时向同一个交换机发送数据。

对于前一种情况，我们可以如下打开mindstudio的通信界面，选择一个跨机通信域（下面的示例不一定是跨机通信域，只是为了演示），然后查看有没有多个卡存在并发通信算子（send过程）。

mindstudio insight “通信”界面

对于后一种情况，我们需要再次使用timeline，在已知哪些卡对应于同一个交换机的情况下（怎么知道这个信息？后续再补充，知道的朋友可以在评论区补充），把这些卡的communication group都置顶进行比较分析，观察是否有通信算子（send过程）的并发行为。

好的，到这里告一段落，主要介绍了如何使用mindstudio insight分析可能产生PFC的场景。