昇腾集群PFC现象分析

简介: 负责集群运维的同学可能都遇到过PFC现象,那么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的场景。

--------------------------

大家有没有遇到过PFC现象呢?欢迎留言讨论!

目录
相关文章
|
10月前
|
机器学习/深度学习 人工智能 Java
机器学习PAI报错问题之跑collective gpu分布式报错如何解决
人工智能平台PAI是是面向开发者和企业的机器学习/深度学习工程平台,提供包含数据标注、模型构建、模型训练、模型部署、推理优化在内的AI开发全链路服务;本合集将收录PAI常见的报错信息和解决策略,帮助用户迅速定位问题并采取相应措施,确保机器学习项目的顺利推进。
|
API 容器 Kubernetes
当 K8s 集群达到万级规模,阿里巴巴如何解决系统各组件性能问题?
作者 | 阿里云容器平台高级技术专家 曾凡松(逐灵) 本文主要介绍阿里巴巴在大规模生产环境中落地 Kubernetes 的过程中,在集群规模上遇到的典型问题以及对应的解决方案,内容包含对 etcd、kube-apiserver、kube-controller 的若干性能及稳定性增强,这些关键的增强是阿里巴巴内部上万节点的 Kubernetes 集群能够平稳支撑 2019 年天猫 618 大促的关键所在。
|
7月前
|
机器学习/深度学习 运维 算法
【KDD2024】面向集群整体作业运行变慢的异常检测
阿里云计算平台大数据基础工程技术团队主导,与浙江大学合作的论文《Cluster-Wide Task Slowdown Detection in Cloud System》被数据挖掘领域顶会ACM SIGKDD2024接收。论文从新的视角分析云计算平台集群健康状态,实现了基于神经网络的集群作业整体变慢异常定向检测,与SOTA异常检测算法相比平均提升F1 score 5.3%。
|
9月前
|
人工智能 资源调度 算法
内附原文|SIGMOD’24:百万核的智能调度,云数仓如何结合AI处理用户混合负载
论文提出的Flux通过使用AI技术将短时和长时查询解耦进行自动弹性,解决了云数据仓库的性能瓶颈,同时支持了资源按需预留。Flux优于传统的方法,查询响应时间 (RT) 最多可减少75%,资源利用率提高19.0%,成本开销降低77.8%。
内附原文|SIGMOD’24:百万核的智能调度,云数仓如何结合AI处理用户混合负载
|
机器学习/深度学习 人工智能 运维
用ML提前预测磁盘故障、智能诊断部署,MSRA在云端将AIOps玩出高度
用ML提前预测磁盘故障、智能诊断部署,MSRA在云端将AIOps玩出高度
281 0
|
Web App开发 缓存 前端开发
谷歌谈SPA架构是如何影响网站核心指标的?
谷歌谈SPA架构是如何影响网站核心指标的?
266 0
谷歌谈SPA架构是如何影响网站核心指标的?
|
机器学习/深度学习 人工智能 运维
用ML提前预测磁盘故障、智能诊断部署,MSRA在云端将AIOps玩出高度
用ML提前预测磁盘故障、智能诊断部署,MSRA在云端将AIOps玩出高度
505 0
用ML提前预测磁盘故障、智能诊断部署,MSRA在云端将AIOps玩出高度
|
SQL 运维 算法
DTCC 2020 | 阿里云梁高中:DAS之基于Workload的全局自动优化实践
第十一届中国数据库技术大会(DTCC2020),在北京隆重召开。在12.23日性能优化与SQL审计专场上,邀请了阿里巴巴数据库技术团队高级技术专家梁高中为大家介绍DAS之基于Workload的全局自动优化实践。 SQL自动优化是阿里云数据库自治服务重要自治场景之一,该服务支撑阿里巴巴集团全网慢SQL的自动优化,目前已累计自动优化超4900万慢SQL。阿里在构建这一能力过程中有经验也有教训,期望从基于Workload的全局优化能力构建历程、智能化自动优化闭环实践两个方面和大家分享。
4381 2
DTCC 2020 | 阿里云梁高中:DAS之基于Workload的全局自动优化实践
|
机器学习/深度学习 数据采集 人工智能
人工智能如何解决数据中心的工作负载管理难题
随着数据中心工作负载量呈螺旋式增长,越来越多的企业开始寻求采用人工智能技术帮助他们减轻IT团队的管理负担,同时提高效率,并削减开支。
389 0
|
数据采集 分布式计算 关系型数据库