APP下载

超算中心典型科研应用特征统计与分析

2022-05-27梁润秋NajiAlhusaini何卓骋

小型微型计算机系统 2022年6期
关键词:调用数据包进程

梁润秋,沈 瑜,Naji Alhusaini,何卓骋,李 京,

1(中国科学技术大学 计算机科学与技术学院,合肥 230026)

2(中国科学技术大学 超级计算中心,合肥 230026)

1 引 言

随着科学技术的不断发展,科研任务对高性能计算的要求越来越高,超算中心已经成为科研机构不可替代的基础设施,为科研的发展提供着强大的推动力,在超算中心中通常大量的计算和存储设备,并用一个专门的网络进行互联,被称之为超算中心网络,在过去的十几年里,尽管学者都对数据中心网络流量的设计改进抱有极大的兴趣,但目前学术界对数据中心的网络流量尚有很大不足,而数据中心的网络流量特征又不同于传统的广域网的流量,与传统网络相比,数据中心网络在规模、运行多样性、高功率、高可靠性等方面有着独特的特点和要求,这些问题给数据中心的优化带来了重大的挑战[1].

中国科学技术大学超级计算中心始建于2003年,是国内高校最早建立的超算中心之一.我校超算中心面向校内所有有高性能计算任务需求的科研院系、实验室、教师、学生提供高性能计算服务.超算中心目前正在运行中的系统有2014年建成的“曙光TC4600百万亿次超级计算系统”和2020年1月投入运行的“瀚海20超级计算系统”,共计1200多台服务器,总计算能力达到3.169千万亿次/秒(PFLOPS).超算中心用户主要来自物理学院、化学院、微尺度国家科学中心等物理、化学等学科,运行的程序主要是VASP(分子动力学模拟软件包软件包,Vienna Ab-initio Simulation Package)、Gaussian、OpenFOAM等科学计算软件为主.由于该超算中心算力高,规模大,任务庞杂,是典型的面向科学研究的超算中心,虽然该超算中心很好地支持了广泛的科研工作,但仍然在网络上存在瓶颈,限制其性能发挥.为了探究其网络存在的问题并且优化其网络架构和改善网络调度,对网络进行详尽的统计和分析是非常重要而且必要的.

对大型超算系统上运行的科学计算应用程序进行优化十分复杂,有效途径之一就是充分利用通信资源来提升应用程序性能、效率和扩展性.MPI[2](消息传递接口,Message-Passing Interface)是科学计算中最常用的多节点通信的编程模型[3],自从1994年MPI概念产生以来,已经推出了9个版本的MPI标准.虽然大部分科学计算应用都采用了MPI,但是超算中心对MPI在应用程序中的使用还缺乏全面的认识,导致这种情况一个主要原因是分析MPI行为特征需要在大型超算系统中抽取海量的数据,而这对超算系统来说,会带来很大的开销.但是理解MPI的细节对高性能中心在很多方面都有着重要的意义.例如,优化应用的通信特征需要了解MPI的详细使用情况,有了这些内容,开发人员和超算中心就可以通过合理利用和分配资源来优化最常见的MPI特性;其次,将这些MPI统计数据提交到MPI标准化机构和社区,来帮助新标准的制定;利用这些统计数据,可以更有针对性采购HPC系统的设备(比如考虑高优先级的API性能).

虽然,已有一些对MPI使用情况的研究,有的是对大规模MPI整体使用情况的研究[4,5],有的是对小规模某个特定应用的研究[6,7],但到目前为止还没有学者针对MPI的主流使用行业——科研机构这一行业进行细致探讨和研究.从一个或几个关键的应用程序里获取数据存在着诸多挑战,本文首次对科研行业的MPI使用情况进行大规模的调查,采集了中国科学技术大学超算中心上百个节点数个月的数据,对MPI底层修改了累计74个函数,对最具代表性且使用最广泛的小规模并行应用VASP和大规模并行应用OpenFOAM的MPI使用情况和流量数据,也就是infiniband包的大小进行分析统计,本文主要统计分析了4个关键特征:1)函数调用次数;2)函数发送接收数据量;3)函数运行时间;4)流量包的大小分布.这是第一次在科研行业对考虑了所有这些特征的MPI程序进行全面的调查.本研究中最重要的发现如下:

科研行业超算中心应用不同于其他一般的超算中心,虽然超算中心中存在这各种各样累计超过16种应用,但是VASP机时占比接近一半,是最影响超算性能的应用;VASP应用运行时存在主进程,调用函数以及流量和其他进程有很大区别;无论是调用次数、数据包数量还是使用时间上,VASP都以全局函数为主;而OpenFOAM非阻塞通信占据了最多的调用次数和数据传输量,但全规约函数MPI_Allreduce却消耗了最多的调用时间;数据包大小呈现明显的分布,RoCE小包占据绝大部分.

2 相关工作

虽然许多先前的研究已经指出通用编程语言在科学与非科学程序中的使用,但很少有研究者关注MPI编程模型的使用.关于MPI在科学程序中的使用的第一次研究可以追溯到1997年[6],这项工作评估了MPI编程模型和其他模型的使用,如科学代码中的PVM和Shmem,但是其目标不是对MPI使用功能的理解,而是评估这些模型的软件复杂性的影响及其对运行时性能的影响,所取数据集也很小.

起初学者们将研究集中在抽取MPI分析数据上.MPI分析工具从一组定义的进程(部分或全部的MPI进程)中为指定的MPI接口例程或在MPI调用堆栈收集重要信息(例如时间、调用计数、消息量).这些分析工具通常可以提供单个MPI应用程序执行的性能信息,例如,mpiP[8]、IPM工具[9-11]和Darshan[12],开发人员使用这些工具来优化代码.MPI追踪工具可以收集感兴趣的事件的执行过程,它们通常可以跟踪记录为每个感兴趣的MPI功能的调用.Vampire[13],DUMPI[14]和the Intel Trace Analyzer and Collector(ITAC)[15]是常用的MPI跟踪工具,追踪工具能提供更精准的数据,但是有很大的性能开销.像CrayPAT[16]、HPCToolkit[17]也曾经被用作对MPI进行分析和跟踪的工具.后来,研究者们开发了一个名为Autoperf[18]的轻量级工具,并且使用它来自动分析在大型超级计算系统上各个应用的MPI使用情况和硬件性能情况.它的输入包括正在运行作业的性能情况日志,对MPI使用PMPI重定向和利用硬件计数器产生的处理器使用数据.它的输出为纯文本格式包括MPI使用情况和性能信息,包括调用了哪些MPI例程、每个例程调用了多少次、每个例程花费的时间以及发送或接收的字节数等信息.它首先过滤掉了测试性能和测试应用的微量级作业,其次排除了那些运行时长比较短不够完整且不能当做应用的作业.学者们首先对MPI的使用时间和MPI中应用的时间进行了分析,发现MPI库所使用的时间比之前大多数超级计算中心所假定的时间要多得多,虽然大多数的数据中心都意识到了MPI的重要性,但是一般认为应用在MPI上花费的时间不超过1/4.研究者发现即使是在大型生产应用中,上述假定也是错误的,实际上,许多应用在MPI上花费了一半以上的时间.

Thakur等[19]为使用Hockney模型的MPI_Allgather,MPI_Bcast,MPI_Alltoall,MPI_Reduce_scatter,MPI_Reduce和MPI_Allreduce例程提出了几种集合算法的分析性能模型.并且在文献[20]中,已有学者致力于研究自动为集合操作选择最佳的算法,可是有很多不足之处,如精度有限,训练时间长.

为了更好地理解MPI的使用,人们做了许多尝试.研究[21]只关注Exascale Computing Project(ECP)的应用.目的是了解MPI使用方面的应用需求,并调查与MPI标准相关的可能问题,以及当前代码是否希望在百亿亿次级计算机上使用MPI.

Sultana等人[4]展示了MPI在ECP代理应用程序套件中的使用情况.本工作首先分析了程序的dvami特性,同时也分析了一些静态特性,介绍了MPI调用使用的分析以及MPI的其他方面,如错误处理、工具、dvnamic进程管理,并对14个MPI程序进行了分析.Klenk和Fróning[22]研究了18百亿亿次级代理程序的动态MPI特性.先前的研究报告了在特定的高性能计算系统和中心的生产程序中MPI的dvnamic使用情况.Rabenseifner[6]报告了Cray T3E和SGI Origin2000系统的动态MPI使用情况.在最近的一项研究中.Chunduri等人[7]在Argonne国家实验室的大型IBM BG/Q超级计算系统(Mira及其相应的开发系统(Cetus)上进行了两年内的MPI iobs分析.

与之前的研究不同的是,本文的研究聚焦于科研行业超算中心,是对超算中心内应用程序和数据包的流量特征进行统计分析,这些数据与分析对超算中心资源分配和设计规划有非常重要的作用和意义.

3 实验平台与数据采集

3.1 实验平台简介

3.1.1 瀚海20超级计算系统

中国科学技术大学超级计算中心瀚海20超级计算系统采用Mellonax HDR 100Gbps高速互联,包括6个组成部分:ARM节点、CPU计算集群、GPU计算节点、AEP计算节点、登录管理节点,以及存储系统,具体结构如图1所示.双精度浮点计算能力约为2.52Pflops(千万亿次每秒).

图1 瀚海20超算中心网络架构

3.1.2 曙光TC4600百万亿次超级计算系统

中国科学技术大学超级计算中心曙光TC4600百万亿次超级计算系统,面向所有有需求注册用户为他们提供高性能计算服务,同时也是安徽省教育科研网高性能计算平台.曙光TC4600百万亿次超级计算系统使用100Gbps和56Gbps进行链接,包括登录管理节点、CPU和GPU计算节点、存储系统、高速计算网络等部分,该系统双精度计算能力约为0.519 Pflops(千万亿次每秒)关于两个系统的详细信息如有兴趣请参照中国科学技术大学超级计算中心系统平台主页.

3.2 数据采集介绍

3.2.1 MPI数据

MPI 是在高性能计算领域中一种常用的通信 API,以其高性能,可移植性和大规模性著称.它为点对点通信提供了一系列技术支持,同时有一套丰富的集合通信接口.点对点通信通常发生在两个进程之间,而集合通信涉及到一个给定的应用程序或作业其子集中的所有进程.MPI定义分布式应用程序中进程之间各种类型的通信操作的语法和语义.如今大多数的 MPI 实现包括MPICH、OpenMPI以及厂商在这些开源的MPI 事先基础上研发的Intel MPI、HPC-X 等都支持最新的3.1版MPI 标准.3.1版支持的新特性有:1)非阻塞集合通信;2)近邻集合通信(阻塞 +非阻塞);3)单边通信增强;4)共享内存扩展;5)新的 Fortran2008 接口;6)新的工具接口(MPI_T).

为了能够记录下实际程序在运行过程中产生哪些流量数据,本文参考Autoperf 的做法,对MPI 的底层进行了修改,修改了OpenMPI 4.0.3的源代码,在数据传输函数中增加了日志功能,记录下每次调用的相关数据参数,包括调用函数的名称、开始时间、通信域、发送进程、接收进程、发送数据量和接收数据量.本文共修改74个函数,除了两个初始化函数(MPI_Init和MPI_Init_thread)和一个终止函数(MPI_Finalize),一共有71 个数据传输函数.

3.2.2 InfiniBand数据包

InfiniBand是一个用于高性能计算的计算机网络通信标准,它具有极高的吞吐量和极低的延迟;Omni-Path Architecture(OPA)是来自Intel的高性能通信架构.RoCE(RDMA over Converged Ethernet)是RDMA(Remote Direct Memory Access)在以太网上的一种主要实现方法,RoCE是一种机制,其提供了在无损的以太网上实现极低延迟的高效通信.由于RoCE在性能和成本上具有明显的优势,因此在NAS存储集群中采用RoCE协议,已经成为了一种主流趋势.TC4600系统分多批次建设,在不同建设阶段分别采用了56 Gbps FDR InfiniBand,100 Gbps Intel OPA和100 Gbps EDR Infiniband组成计算网络.这些计算网络分别连接不同的计算节点,在用户进行计算时,同一个程序只会在同样的计算网络内并行运行而不会跨不同的计算网络运行.本文在采集数据的时候不用考虑不同类型或者不同速率网络的混合并行.

Mellanox为Infiniband网络提供了类似tcpdump的抓包工具ibdump,它可以转储流入和流出的InfiniBand流量,然后通过Wireshark工具加载,用于图形化的流量分析.它提供了分析网络行为和性能的能力,以及调试发送或接收InfiniBand网络流量的应用程序.

由于超算中心数据流过大,科研计算程序运行时在计算网络上传输的数据量非常大,本文直接使用ibdump转储流量数据时,发现可能几秒钟就产生了数十GB的文件.而一个简单的计算任务短则几十分钟,长达几十天.另一方面,本文在分析流量性能而不是对程序进行调试时,并不关心传输的数据内容,而只关心数据的属性,例如时、大小等等.然而ibdump并没有像tcpdump一样提供了只保存数据包头部的选项,因此联合使用tshark工具,将ibdump获取的数据信息通过管道传给tshark,过滤掉无用信息后再保存下来.保存下来的数据为tshark的默认输出格式,一般包含时间、来源、目的、协议、包大小等信息.

为了能够准确获取到程序运行时候的数据,本文提取了在TC4600系统上用户实际运行的程序输入文件,使用修改过的带日志功能的OpenMPI编译的VASP运行计算任务,记录下MPI消息传输日志,同时使用ibdump和tshark来获取运行时的infiniband网络流量信息.

本文分别采用ibdump(在Infiniband网络上)和tcpdump(在ROCE v2网络上)对运行时候的计算节点的网络接口进行了数据抓包.

4 vasp应用统计分析

4.1 介绍

VASP是使用第一性原理的原子尺度材料计算软件.是我校超算中心上使用范围最广、计算机时最多的科学计算软件.VASP采用MPI并行设计,一般并行规模在几十个进程到几百个进程之间,使用节点个数从1个~10个节点不等.VASP使用了大量的双精度矩阵计算和FFT计算,对CPU、内存、网络的要求都很高.

图2统计了中科大超算平台主要应用的机时占比。如图2所示,在我校超算平台上VASP应用在服务器上的运行时间高达49%,机时占比接近一半,是最影响超算服务性能的应用软件,由于超算中心用户主要来自物理学院、化学院、微尺度国家科学中心等物理、化学等基础学科,所以超算中心的应用呈现高度的集中性,前5大应用软件包机时占比高达86%.

图2 中科大超算平台上主要应用的机时占比

本文选择了实际超算系统上运行过的VASP作业,在瀚海20超级计算系统上的华为FusionServer X6000双路CPU计算节点上,采用本文修改过的OpenMPI运行这些作业,同时采集数据并进行分析.

测试平台基本配置为:2×Intel Xeon Scale 6248(20核,2.5GHz),192GB DDR4 2933MHz内存,总共720个节点,计算网络是Mellanox HDR 100Gbps,两层胖树结构.

4.2 统计分析

本文首先统计了MPI函数调用情况,图3是记录的MPI传输函数的调用次数、发送和接收数据量、和消耗时间的统计.为了清晰起见,本文只展示了3个进程,分别是0号进程(0号进程除了进行计算,通常还负责处理输入输出等工作)和0号进程在同一个节点的23号进程以及在另外一个节点的47号进程.

从图3中可以看出,VASP在运行时主要调用的数据传输函数以全局通信函数为主,包括MPI_Bcast、MPI_Alltoall、MPI_Allreduce和MPI_Alltoallv,至于点对点函数,除了0号进程调用了大量的MPI_Recv,其他函数相比较就少很多.从发送和接收数据量上来看全局通信函数远远超过点对点通信函数,另外调用次数最多的全局通信函数MPI_Bcast发送接收的数据量都相对很少,而传输数据量最多的分别是MPI_Alltoallv、MPI_Alltoall和MPI_Allreduce.从函数运行时间来看,首先,相比传输数据量,调用次数对时间的影响更加明显,这表现在调用次数较多的MPI_Bcast时间相比传输数据量更多的MPI_Alltoallv和MPI_Alltoall使用了更多的时间,而且点对点接收函数MPI_Recv也使用了相当长的时间;更值得注意的是,尽管MPI_Allreduce调用次数和传输数据量都不是最多,但它消耗的时间却最长,这可能是它需要进行一些简单的数据处理操作,这些操作会对性能有比较明显的影响.

图3 VASP应用进程0、23、47号的MPI接口调用的次数(a)、数据量(b)和执行时间(c)

本文还统计了运行作业的两个节点的网络接口数据包的统计情况,图4是数据包大小的统计.

从图4可以看出,VASP在运行时存在,存在3个典型大小的数据包,接近0、1.6k和4k左右大小.接近0的应该是一些单独一个变量而不是整个数组的传输,4k大小应该是一些大的数组在传输时被切分后的大小.这两个占据了数据包的主要部分.

图4 VASP应用infiniband数据包分布

5 OpenFOAM应用统计分析

5.1 简介

OpenFOAM是一个完全由C++编写的面向对象的CFD类库,采用类似于日常习惯的方法在软件中描述偏微分方程的有限体积离散化,支持多面体网格,因而可以处理复杂的几何外形,支持大型并行计算.

为了进行大规模并行测试,本文邀请用户提供的一个典型的OpenFOAM作业,在瀚海20超级计算系统上的华为Taishan 2280V2国产ARM CPU计算节点上,采用本文修改过的OpenMPI运行这些作业,同时采集数据并进行分析.

测试平台基本配置为:2×海思Hi1620 CPU(48核,2.6GHz),256GB DDR4 2666MHz内存,共计20个可用节点,计算网络是100GB 支持ROCE v2的以太网,交换机是华为CE8800-64数据中心交换机.由于平台网络刚刚升级完成,本文仅测试了8个节点和16个节点的运行情况.

5.2 8节点并行测试

本文同样统计了MPI传输函数调用的情况,使用8个节点进行计算的并行规模达到了768个进程,本文选取了第1个节点、第2个节点和最后一个节点上面各一个进程进行分析.

通过对MPI传输函数的日志进行分析可以发现OpenFOAM调用的MPI传输函数种类较少,只有MPI_Alltoall、MPI_Allreduce、MPI_Isend、MPI_Send、MPI_Irecv和MPI_Recv这6个.这些函数的调用次数统计见图5,从图中可以看出非阻塞发送和接收函数调用次数远远大于其它函数(请注意纵坐标为指数坐标),MPI_Allreduce虽然要比非阻塞点对点通信函数少一个数量级,但比MPI_send、MPI_Recv和MPI_Alltoall还是要多2~4个数量级.

图5(b)为各个函数发送和接收的数量统计,和调用次数类似,非阻塞点对点通信的数据传输量远远大于其他函数,MPI_Allreduce仅次于这两个函数,而远大于其他函数.然而,对于函数调用的时间,由于非阻塞的函数不需要等待数据传输完成即可返回,使得调用时间仅仅不能反应实际数据传输需要的时间,这样,调用次数和传输数据量仅次于非阻塞函数的MPI_Allreduce就占据了传输时间的最主要部分.

图5 8节点OpenFOAM应用MPI接口调用次数(a),数据量(b)和执行时间(c)

本文采用tcpdump采集了发送到本机4791端口的数据包,分析了ROCE v2数据包大小情况(见图6).研究发现,图6左边非常小的数据包占据了绝对主要的部分;其次是最大值约1k大小的数据包,表现在图上是最右边略微抬起的一小段.跟VASP相比,OpenFOAM更倾向于使用短消息进行数据通信.

图6 8节点OpenFOAM ROCE v2数据包分布

5.3 16节点并行测试

在使用16个节点并行计算时,程序并行规模达到了1536个进程,这时,从第1个节点、第2个节点,中间节点和最后一个节点上面各选取了一个进程进行分析.

图7分别是MPI函数调用次数、数据传输量和调用时间.当实验由8个节点扩展到16个节点后,对比两次实验的数据图,可以发现MPI函数调用次数没有明显变化,而MPI_alltoall的发送接收数据量随着节点的上升有明显地提升,且在运行时间上,全局函数随着并行规模的增加,运行时间占比有显著提高,实验中将节点提升至一倍运行时间约提升了0.4个数量级,而点对点通信随着并行规模的上升没有发生什么变化;本文可以得到与8个节点并行计算时类似的结论:OpenFOAM调用的MPI传输函数种类同样比较少,只有6个常用的MPI函数.非阻塞通信占据了最多的调用次数和数据传输量,但全规约函数MPI_Allreduce却消耗了最多的调用时间.

图7 16节点OpenFOAM应用 MPI接口调用次数(a),数据量(b)和执行时间(c)

在16个节点的并行实验中,同样采用tcpdump采集了数据包,统计了节点接收到的ROCE v2数据包的大小信息.在16个节点并行时,极小包的占比更多,超过90%,说明随着并行规模的增加,数据交换量的增加,短消息会占更大的比重,这是因为节点频繁沟通而产生的小数据包,他们会起更重要的作用.数据包分布如图8所示.

图8 16节点OpenFOAM ROCE v2数据包分布

6 结论与展望

在高性能计算领域,超级计算机上运行的大部分的应用程序都属于计算密集型程序,在这些应用程序的计算过程中需要耗费大量CPU或GPU的计算资源,且通常伴随着多种类型的点对点通信和集合通信,其对通信的带宽、时延均很敏感[3].科研行业的超算中心所执行的任务和普通的超算中心有很大区别,而且是极具特点的.随着科技水平的发展,科研任务对超算中心性能的要求也水涨船高,而网络作为一个庞大的超算中心数百个节点交流的桥梁,对整体性能的影响颇深,针对科研行业的超算中心网络进行优化就需要先对其进行统计分析.

首先根据本文的实验结果,无论是在InfiniBand网络环境还是在本文的重要研究对象—以太网 RoCE协议网络环境下,超算应用的MPI调用都有很大的优化需求,尤其是MPI_Allreduce等集合通信函数在通信中占比很大,具有很大的优化空间.

在本文的超算任务中,VASP应用的机时占据所有应用的一半,分别对小规模并行的VASP应用和大规模并行的OpenFOAM应用的并行数据传输特征进行了分析,发现无论是在小规模并行的VASP、大规模并行OpenFOAM,尽管全局规约函数MPI_Allreduce的调用次数或者传输的数据量不是最多的,但它仍然占据了主要的数据传输时间,由于这个函数需要进行简单的数据处理操作,使得这个函数的优化程度要低于类似的全交换函数MPI_Alltoall.在下一步的研究中,将针对上述问题,在交换机上采用硬件加速或者设置修改参数(Infiniband和RoCE)来提高整个网络通信速度,提高并行计算时的速度和扩展性.同时在网计算可以有效地解决超算中心应用程序中的集合通信和点对点通信上的瓶颈问题[23,24],而超算中心应用的MPI调用都有很大优化需求,尤其是MPI_Allreduce等集合通信函数在通信中占比很大,使用在网计算技术对此类集合通信操作进行优化有非常强的可行性;考虑利用在网计算技术对于以太网 RoCE协议下应用的MPI通信进行优化,将极大的提高超算系统应用的整体性能,减少通信的延迟.

本文还发现,主要采用FORTRAN实现的VASP对全局通信和大规模批量数据传输的MPI函数调用比较多,而采用C++实现的OpenFOAM对非阻塞点对点通信和小数据量的MPI函数调用更多一些,这使得对网络的需求有着明显的不同,接下来将有针对性的设计网络控制参数,对流量进行调度,提高网络传输性能.

另外,通过本文的分析发现,在大型并行计算中,小数据包占比极大,这意味着节点通信更为频繁,且在VASP应用中存在主进程,那么对于现在数据中心的树状网络结构,就有很大劣势,接下来将会对应用行为特征进行更为广泛的研究,并探求性能更优的网络结构.

猜你喜欢

调用数据包进程
基于时隙ALOHA与NOMA的通信系统性能分析
Dalvik虚拟机进程模型研究
C#串口高效可靠的接收方案设计
快速杀掉顽固进程
不留死角 全方位监控系统
基于Android Broadcast的短信安全监听系统的设计和实现
中外民主法制进程专题复习
网络数据包的抓取与识别
利用RFC技术实现SAP系统接口通信
C++语言中函数参数传递方式剖析