领先级HPC上的机器学习工作负载的I/O性能分析
Source: Ahmad Maroof Karimi, Arnab K. Paul, and Feiyi Wang, I/O performance analysis of machine learning workloads on leadership scale supercomputer, October 2022
摘要
机器学习技术和框架的普及导致越来越多的机器学习工作负载运行在高性能计算（HPC）集群上。机器学习工作流在生物学、物理学、材料学和计算机科学等不同的计算领域得到广泛应用。新兴的机器学习工作负载的I/O行为与传统的HPC工作负载（如模拟或基于检查点/重启的HPC I/O行为）明显不同。此外，机器学习工作负载还推动了在计算任务中使用GPU或CPU与GPU组合，而不仅仅使用CPU。机器学习工作负载多样而复杂的I/O行为需要进行深入研究，并且对于I/O栈的各个层以及HPC工作负载的整体性能至关重要。
本研究旨在填补对新兴机器学习工作负载的I/O行为理解的空白，通过对运行在大规模领先级HPC系统上的机器学习作业进行深入分析。具体而言，我们分析了基于作业规模、科学领域和机器学习作业使用的处理单元的行为。该分析是基于从Summit收集的1年Darshan日志中的23,000个机器学习作业完成的。我们还通过将Darshan数据集与Summit上处理单元的功耗使用情况进行合并，收集了15,165个机器学习作业的CPU和GPU使用情况。因此，本文能够对领先级HPC机器上机器学习工作负载进行系统的I/O表征，以了解不同科学领域、工作负载规模和处理单元的工作负载的I/O行为差异，并分析并行文件系统和Burst Buffer在机器学习I/O工作负载中的使用情况。
通过多种分析研究，我们对I/O性能和访问模式做出了几个观察，并从机器学习用户和存储架构师的角度讨论了在大规模超级计算机上运行新兴机器学习工作负载的重要经验教训。
1. 引言
随着机器学习（ML）和深度学习（DL）技术越来越受到关注，特别是用于解决大规模和复杂的建模问题，高性能计算（HPC）系统的I/O使用模式正在与传统工作负载所展现的模式发生分歧。传统工作负载（如模拟、可视化或基于检查点/重启的工作负载）观察到的I/O行为与ML和DL作业的复杂I/O行为不同，后者涉及多个子任务，在大量批次和众多时期的训练中应用大量的读取I/O调用。这些任务涉及的数据集也是异构的，包括图像、文本和时间序列向量。生物学、物理学和化学等各种科学领域，为大规模数据分析和ML/DL工作负载带来了更加多样化的I/O模式[1]。HPC工作负载对I/O的多样性需求，使得有必要对现代和未来的HPC中心的I/O需求进行特征化。
已经有一些研究[2-5]专门用于对传统工作负载（如涉及写入密集的检查点/重启的模拟）进行特征化。近期的研究[6-9]也专注于分析流行的ML方法（如深度学习）的I/O需求。然而，缺乏针对HPC系统的全面横断面分析的研究，该研究可以提供对ML工作负载的典型I/O特性的全面理解。ML工作负载通常遵循几个标准步骤，如从文件系统中读取数据，处理和组织数据，并将其传递给ML训练算法。通常观察到ML工作负载具有小的读写访问模式。读取调用通常在整个数据集上的训练期间以小批次进行。然而，基于不同的领域科学、应用程序、ML作业的规模以及CPU/GPU利用率，I/O调用可能变得非常复杂，特别是在拥有数千个节点的大规模HPC系统上。
有各种I/O监控工具可用于记录HPC存储系统的性能。其中之一是Recorder [10]，它可以在不修改应用程序源代码的情况下捕获并记录并行文件系统I/O栈多层次的I/O函数调用。名为RIOT [11]的I/O工具包提供了一个强大的框架来分析并行文件系统的I/O行为。Darshan [12-14]是最广泛使用的HPC工作负载性能系统级分析工具之一。它旨在捕获应用程序I/O行为的准确情况，包括访问模式等属性，并以最小的开销提供单个文件级别的I/O指标。它轻量级且可以高效地部署在HPC系统上。它为潜在的性能优化工作提供了有价值的洞察，并使得可以对整个HPC集群的I/O趋势进行评估。Darshan日志已经被用于许多研究中来描述HPC工作负载的I/O需求。然而，Darshan并没有将日志进行ML和非ML工作负载的标注。因此，将这两种HPC工作负载（ML和非ML）进行分类是一项非常棘手的任务，这将有助于特征化不同的HPC I/O行为。
大多数机器学习（ML）作业被认为是读密集型的，有许多小型读取操作，而少数ML作业也会执行小型写入操作。这种I/O行为表明，对于ML工作负载而言，像Burst Buffer[15]这样的系统内存储将比并行文件系统（如IBM Spectrum Scale（GPFS）[16]）提供更好的I/O性能，因为后者的性能受大量元数据请求的限制。另一方面，Burst Buffer是位于计算节点非持久性内存和持久性存储（并行文件系统）之间的快速和中间存储层。Burst Buffer层被配置为以非常高的速率接收突发的读取或写入I/O。然而，以前没有对大规模ML I/O工作负载使用Burst Buffer和并行文件系统的研究。
ML科学家和工程师通常更关注作业的计算部分，从而忽视了I/O组件的性能。因此，研究ML作业在使用不同处理单元（CPU和GPU）时的I/O效果非常重要。使用仅GPU的ML作业在I/O性能方面是否优于仅使用CPU的作业？不同的科学领域如何使用处理单元和底层存储系统？
本文旨在填补文献中的空白，通过对不同科学领域、ML I/O作业运行规模和一年内的时间趋势进行特征化，来表征ML工作负载的I/O行为。我们还分析了ML I/O工作负载对并行文件系统和Burst Buffer的使用情况。为此，我们研究了23,389个HPC ML I/O作业的Darshan日志，涵盖了一年的时间（2020年1月至2020年12月），这些作业在全球第二快的超级计算机Summit [17]上运行，根据最新的top-500排行榜[18]。IBM Spectrum Scale（之前称为GPFS）[16]构成了Summit的并行文件系统。在本文的其余部分，我们使用“GPFS”一词表示并行文件系统，“BB”表示Burst Buffer。
本文扩展了我们之前的工作[19]，通过将运行在Summit上的ML作业的Darshan日志与CPU和GPU的功耗数据合并起来。Darshan数据集本身并没有提供关于CPU和GPU层使用情况的足够信息。将Darshan数据与功耗记录合并使我们能够分析I/O对计算节点处理单元（CPU和GPU）的影响。通过合并这两个数据集，我们得到了15,165个ML作业的CPU和GPU使用情况。
具体而言，我们在领先级HPC系统上的ML工作负载的I/O行为方面做出了以下贡献：
开发一种从Darshan日志中注释ML工作负载的技术。
分析不同科学领域和作业运行规模分类的大规模ML工作负载的I/O行为。
研究ML I/O作业对并行文件系统和Burst Buffer的使用情况，了解I/O性能改进的空间。
估计由不同科学领域提交的ML作业对存储子系统不同层次造成的I/O效应，这些科学领域是根据CPU和GPU使用情况进行分类的。
了解在GPU上运行的工作负载执行期间可能导致的I/O行为和潜在瓶颈。
通过我们的研究，我们观察到ML工作负载生成大量的小文件读取和写入，这对于Burst Buffer来说是理想的。然而，只有少数科学领域使用Burst Buffer，并且其中只有一部分有效地使用Burst Buffer。Summit上ML工作负载的时间趋势也显示出不同科学领域的ML工作负载的I/O活动呈指数增长，这预示着未来将由ML主导。我们还发现，仅使用GPU的作业比仅使用CPU的作业造成更严重的I/O瓶颈。根据我们的观察，我们还列出了对ML科学家和存储架构师有益的关键讨论点。
2. 背景
2.1. Summit超级计算机
Summit超级计算机是基于IBM AC922系统，并部署在橡树岭国家实验室（OLCF）。它由4,626个计算节点组成。每个节点配备有2个IBM POWER9（P9）处理器和6个NVIDIA Tesla V100（Volta）GPU。此外，每个节点有512 GB的DDR4 CPU内存，每个GPU有16 GB的HBM2内存。一个NVLink 2.0总线将每个P9 CPU连接到3个V100 GPU。Mellanox InfiniBand增强数据速率（EDR）网络采用胖树拓扑连接这些节点。Summit的峰值功耗为13兆瓦，目前在Green500榜单上排名第11位，每瓦特提供14.719 GFlops，由一个20兆瓦的设施支持，为计算集群提供必要的电力和冷却。每个计算节点都配备了一个1.6 TB的NVMe设备，用作节点本地存储 - Burst Buffer（BB）。Summit与Alpine相连，后者是一个250 PB的IBM Spectrum Scale（GPFS）文件系统。Summit可以在大量和顺序写入I/O访问模式下以2.5 TB/s的速度访问Alpine。Alpine是一个中心范围的文件系统，所有其他OLCF资源都可以直接访问。
2.2. Darshan - HPC I/O特征化工具
图1提供了Darshan架构的概述。当应用程序执行时，MPI、POSIX和STDIO的Darshan仪器化模块会生成数据记录，用于描述应用程序的I/O工作负载在I/O栈的不同组件中的情况。各个组件的仪器化模块会向Darshan核心库注册。在应用程序关闭时，每个模块会整理其记录，进行压缩并将其共同写入日志文件。MPI-IO被记录为每次MPI_File_read()和MPI_File_write()调用。POSIX模块记录每个read()和write()调用。许多应用程序在领先级计算设施中依赖文本型I/O。STDIO模块对stdio.h函数族进行特征化，如fopen()、fprintf()和fscanf()。我们分享了从Summit超级计算机收集的一个月的Darshan日志。
3. 研究方法
3.1. 标注ML作业
Darshan提供了darshan − util，一个用于解析和汇总Darshan仪器化模块生成的日志文件的工具集合。我们使用其中的一个工具darshan − parser，对一年（2020年1月至2020年12月）的原始Darshan日志进行解析，并获取应用程序访问的每个模块（MPI-IO、POSIX或STDIO）中的文件I/O统计信息。每个解析的Darshan日志的元数据包括jobid、userid、start_time、end_time、executable、no_of _processes和runtime。这些解析的日志用于标注ML作业并研究它们的I/O行为。
为了从解析的Darshan日志中识别ML I/O工作负载，我们从在领先级HPC系统上最常用的ML库中创建了一个ML关键词列表。通过浏览前两个月的Darshan日志中出现的可执行文件和文件名，我们发现大多数HPC ML工作负载使用来自R或Python的库。结合在前两个月的Darshan日志中发现的ML术语的知识，并搜索在R和Python中使用的顶级ML/DL库，创建了包含42个ML关键词的列表，如表1所示。这个关键词列表可能并不全面，但足以提供足够代表Summit上的ML作业的样本。
将Summit的调度程序日志与Darshan日志合并，以获取ML作业运行的科学领域（物理学、化学、计算机科学或其他）和节点数量。2020年Summit上总共运行了845,036个作业。其中，279,642个作业生成了Darshan日志。将整个年份的Darshan日志中的可执行文件和文件名与表1中显示的ML关键词列表进行对比，并得到2020年在Summit上运行的23,389个ML作业的最终Darshan日志数据集，该数据集用于本文的分析。
数据集中的最终ML作业数量接近整个2020年在Summit上运行的作业数量的9%。由于先前的I/O分析研究通常是在一月的超级计算工作负载上进行的，其中作业数量少于10,000个[20]，因此我们认为这是足够大的作业数量，可以提供合理的观察结果。此外，上述过程过滤ML作业的过程确保数据集不包含任何错误的阳性样本。然而，无法确定真正的阴性样本，即在上述过程中被遗漏的ML工作负载。这是该领域的一个现有挑战。即使是手动检索来自ML领域的工作负载，也表明甚至并非所有来自ML领域的工作负载都可以归类为ML。因此，唯一的选择是采用文件名或可执行文件中的关键词。这确保了我们的观察结果不会偏向传统的基于模拟的HPC工作负载。
3.2. 节点处理单元功耗和错误管理
我们通过聚合在作业运行时每个节点上记录的值来计算此工作中使用的作业功耗测量。功耗数据是在每个节点上以1赫兹的频率收集的，基于从500微秒瞬时功耗测量中进行的采样。记录的功耗数据具有CPU功耗、GPU功耗和总功耗的独立字段。我们对聚合值进行了验证，与将功率分配给计算机机柜的主开关板（MSB）的测量进行比较。主要是，我们比较了每个节点10秒均值输入功率在每个MSB下所属的总和。总体而言，我们使用每个节点10秒均值功率的聚合值与实际物理MSB测量值相差约11% [21]。然后，我们计算了在所有运行作业的节点和作业持续时间内的平均值，以得到作业的平均功率值。
4. ML I/O工作负载分析
4.1. 基于科学领域的分类
科学领域是根据执行作业的项目代码对工作负载进行高级分类。我们根据代码将每个项目映射到一个科学领域，并且多个项目可能属于一个科学领域。根据科学领域对ML工作负载进行分析是必要的，因为不同科学领域的应用性质表现出显著不同的I/O行为。
4.1.1. ML I/O作业的分布
分析ML I/O作业以确定在其HPC应用中最常使用ML技术的科学领域。图2显示了不同科学领域中的ML作业分布，以及使用ML技术的HPC作业中使用ML技术的用户数量和唯一应用程序数量。如第3节所述，共分析了23,389个ML作业。
观察：生物学在Summit上占据了一年中ML作业的最大比例。然而，计算机科学拥有使用ML方法的最多用户数量。
4.1.2. 使用GPFS和BB的作业
图3显示了每个科学领域中的ML作业数量，这些作业在BB上至少有一个文件访问（BB作业），或者所有文件访问都专门在GPFS上（GPFS作业）。
观察：计算机科学中使用BB的作业数量最多，超过其他科学领域。只有四个科学领域（生物学、计算机科学、材料和化学）在其ML工作负载中使用BB。与普遍观点相反，该图表显示了使用BB的情况仅限于来自选定领域科学的用户，并且可能反映出各个科学领域对于通过不同的科学领域改进I/O性能的BB技术的了解有限。
4.1.3. ML I/O作业的类型
对于使用BB的每个科学领域，我们将每个作业分类为三种类别之一：读取密集型（RI）、写入密集型（WI）和读写（RW）。
观察：计算机科学和化学具有较高比例的RI ML作业，这些作业的所有文件都在GPFS上。因此，来自计算机科学和化学的大量读取-heavy文件可以从GPFS迁移到BB，以改进ML工作负载的I/O性能。
4.1.4. GPFS和BB中ML I/O作业的I/O活动
图4显示了使用BB的四个科学领域中ML作业的I/O行为的密度分布（x轴：写入字节数，y轴：读取字节数）。根据上面讨论的作业类型（RI、WI、RW），该图表表明接近x轴且远离零的作业是WI，接近y轴且远离零的作业是RI，而中间的作业是RW。图4与表2一致，表2显示计算机科学和化学ML作业中使用BB的作业大多是WI，而来自材料学和生物学的使用BB的ML作业大多是RI。
观察1：使用BB的ML作业可以分类为读取密集型或写入密集型，而大多数作业仅使用GPFS的作业是读写型。这需要进一步调查ML工作负载的读取和写入访问大小，这在第4.1.5节中讨论。
观察2：执行较少读取和写入（接近y轴的零点）的大量ML作业仅使用GPFS。这表明许多ML用户认为执行较少的I/O会导致从GPFS复制文件到BB的开销远高于通过在BB上执行I/O获得的I/O性能改进。
4.1.5. 读取和写入访问大小
表3（a）和表3（b）显示了不同访问大小中每个ML作业使用的平均读取和写入调用次数。各种文件访问大小被分为五个桶：小于1MB，1MB-10MB，10MB-100MB，100MB-1GB和大于1GB。此分析很重要，因为大的顺序读取和写入（较大的桶）可以从GPFS获得更高的性能，而小的读取和写入（较小的桶）在BB上更高效。不同科学领域的分类显示不同桶中的调用次数取决于科学领域。同时，所有科学领域的大量I/O调用都属于最小的<1MB桶。
观察：几乎99%的ML工作负载的读取和写入调用次数都小于10MB。这意味着burst buffer是一个优秀的选择，用于改进I/O性能，因为大量的小的读取和写入请求会过载并行文件系统。特别是在Physics领域，该领域占据了Summit上大量的ML I/O作业，如图2所示，存在大量的I/O性能改进空间，但该领域并没有像图3中显示的那样使用burst buffer。
4.2. 基于作业规模的分类
我们根据作业执行的节点数量定义作业的规模。根据节点数量对作业进行分类的原因是，通常在大量节点上运行的大型作业会对HPC系统的性能产生不同的影响，而在少量节点上运行的小型作业可能对HPC系统的性能影响较小。
4.2.1. ML I/O作业的分布
根据Summit的调度策略[22]，ML作业分为三类：小规模、中等规模和旗舰规模。每个类别的描述如表4所示。图5显示了不同科学领域中小规模、中等规模和旗舰规模的ML作业分类。
观察：超过78%的ML作业在少于45个节点上运行，其中生物学和计算机科学占据了最大的作业比例。在中等规模的ML作业中，生物学占据了三分之二以上的份额，而计算机科学和物理学则在77个旗舰规模的ML作业中占据了最大份额。
4.2.2. 使用GPFS和BB的作业
图6显示了具有至少一个文件在BB上访问或所有文件在GPFS上访问的ML作业的数量。
观察1：只有来自计算机科学的ML用户在旗舰规模的作业中使用BB，而来自其他领域的ML用户（生物学、材料和化学）在少于922个节点上运行的作业中使用BB。这可能是因为这三个科学领域的多个传统代码库正在逐步扩展以包括BB并改善I/O性能。
观察2：通常，至少有一个文件在BB上的作业数量少于完全使用GPFS的作业数量。与这种模式相反的是，旗舰规模的计算机科学作业使用BB的数量超过了仅使用GPFS的作业数量。
4.2.3. GPFS和BB中不同类型作业的I/O活动
不同类型的作业：RI、WI和RW，在第4.1.3节中已描述。表5显示了不同类型的作业根据ML作业的规模如何使用GPFS和BB。
观察1：完全使用GPFS的旗舰规模作业更具有读取密集型。因此，如果这些RI ML作业可以将读取-heavy文件从GPFS迁移到BB，则可以改进I/O性能。
观察2：至少有一个文件在BB上的中等规模作业更多地用于WI作业。这意味着ML用户可能不太相信使用BB可以改善读取性能，而仍然更喜欢以传统方式使用BB，即用于捕获周期性的写入突发。
4.3. ML I/O作业的时间趋势
在这一小节中，我们分析了ML作业在一年内的每月行为。对ML工作负载的时间分析将揭示新兴ML工作负载的I/O行为。
4.3.1. 高层次的I/O趋势
图7通过累积分布函数（CDF）图显示了ML作业在一年内I/O特性的演变，其中包括读取和写入的字节数。
观察：超过50%的I/O发生在年后半段（从8月中旬开始）。这表明在HPC工作负载中，ML技术的使用呈指数增长，因此有必要进行此类研究以构建更好的技术，以满足未来这类ML应用的I/O需求。
4.3.2. 不同科学领域的ML I/O行为趋势
图8(a)和8(b)显示了四个使用BB的科学领域对GPFS和BB上ML作业读取和写入字节的百分比的时间趋势，该趋势跨越一年。
观察1：计算机科学的用户比其他科学领域更早开始在其ML作业中采用BB。在化学、材料和生物学中，BB的使用量急剧增加，这表明在很短的时间内只有少数用户使用了BB。图8(b)与图7的趋势相同，在年的后几个月中运行了大部分的ML作业。因此，计算机科学领域之外的学科领域开始更普遍地为其ML工作负载使用BB，并且这种趋势将持续增长。这意味着需要开发更好的I/O优化方法来更高效地使用Burst Buffer。
观察2：在GPFS和BB上的读取和写入的时间趋势是相似的，但计算机科学的读取趋势除外，表明在年初用户可能进行了一些基准运行，以测试BB的读取性能，然后再将BB用于ML应用中。
4.4. ML I/O作业对Burst Buffer的使用
正如在第4.1.5节中所述，大量的小读取和写入构成了ML工作负载的I/O行为，这比GPFS更适合BB。因此，在本节中，我们分析了ML作业对BB的使用情况。在总共23,389个ML作业中，只有1046个作业使用了BB。
4.4.1. 在BB和GPFS上存在相同文件的作业
写入密集的ML作业通常使用BB进行临时写入，然后将其持久化到GPFS。另一方面，读取密集的ML作业将文件从GPFS复制到BB，然后从BB读取文件以提高ML作业的整体读取性能。因此，从所有使用BB的1046个ML作业中，我们仅分析了在GPFS和BB上都有共同文件的作业，并观察这些共同文件的读取和写入字节的分布。图9(a)和9(b)显示了根据使用GPFS和BB的共同文件来分类的RI、WI和RW作业的百分比，这些作业是根据科学领域和作业规模分类的。我们找到了一共396个在GPFS和BB上都有共同文件的作业。
观察1：图9(a)显示，来自生物学的ML作业执行了持久性写入，而其他类型的作业没有任何共同文件。这与来自化学的ML作业的行为完全相反，其中WI作业没有任何被持久化的文件。来自材料学的作业仅为RI作业，其中一些使用BB来提高读取性能。计算机科学领域的ML用户试图通过所有三种类别的作业，即RI、WI和RW，使用BB来改善读取性能或将大量写入-heavy文件从BB持久化到GPFS。
观察2：图9(b)显示，所有规模的作业的共同文件的趋势都由图9(a)中的计算机科学所主导。然而，随着科学领域其他于计算机科学的学科采用了更多的ML技术，Burst Buffer的使用将偏向于亚优化的BB使用方式。因此，为了实现系统范围内的最佳I/O性能，ML用户需要对BB的好处有很好的了解，并且需要开发类似于[23,24]的新型I/O优化技术，可以在不更改传统代码库的情况下透明地使用BB。
4.4.2. 从BB持久化到GPFS的文件的I/O活动
图10显示了使用BB的ML作业的I/O分布，以评估从BB持久化到GPFS的数据大小。Total bytes read/written是使用BB的ML作业的总读取或写入字节数。Burst buffer bytes read/written是从BB读取或写入的总字节数。Persisted bytes read/written显示了从BB读取或写入后持久化到GPFS的文件大小。
观察：从BB读取的文件的字节没有持久化回GPFS。而且，正如预期的，计算机科学中几乎所有来自BB的写入字节都被持久化到GPFS。然而，化学领域的情况并不符合此规律，他们没有将在BB上进行的写入字节持久化。这可能意味着化学领域的ML作业可能写入了许多不需要被持久化的临时文件。
4.5. ML I/O作业在GPFS和Burst Buffer上的性能
在本节中，我们分析ML I/O作业通过更高效地使用BB所能获得的性能提升。
4.5.1. 读取与写入性能
表6比较了ML作业在GPFS和BB上文件的读取和写入性能的均值、中位数和标准差。
观察1：在BB上，读取和写入性能都优于GPFS。与GPFS相比，BB对读取性能（4.95倍）的改进优于写入性能（3.48倍）。
观察2：根据BB上的均值和标准差，我们可以得出结论，66%的读取和写入性能在1GBps和6GBps之间。这与可以从Summit上的单个节点上获得的BB的理论峰值相符——写入2.1 GBps，读取5.5 GBps。
4.5.2. 不同科学领域的I/O性能
表7(a)和表7(b)显示了通过科学领域分类的ML作业的读取和写入性能，当它们要么完全使用GPFS，要么至少有一个文件从BB进行访问。来自化学领域的ML作业没有在BB上进行任何读取，而来自材料学领域的作业在BB上没有写入，因此相应的值为零。
观察1：所有领域的BB上的读取和写入性能都超过GPFS。这表明通过更高效地使用BB，性能可以大幅提升。
观察2：计算机科学领域的ML作业在GPFS和BB上的文件访问的平均性能比其他领域要好。这意味着计算机科学领域更好地利用了BB和GPFS，例如，在ML作业执行的总体I/O较小时不使用BB，将读取密集的文件从GPFS复制到BB后再在BB上进行读取，在BB上捕获写入密集文件的写入突发，然后再将其持久化到GPFS。这再次表明，对于对BB了解较少的学科领域，应该开发更好的优化技术，可以在GPFS和BB之间透明地迁移文件。
4.6. 基于处理单元使用的ML I/O作业性能
从电源数据集中，我们获得了每个作业在CPU和GPU上的平均功耗。将电源数据与Darshan数据集结合起来，我们能够分析ML作业的I/O性能，根据作业使用的CPU和GPU进行分类。
4.6.1. ML作业的分类
我们将用于I/O模式分析的Darshan数据集与电源数据集结合起来，将工作负载分为三类：仅使用GPU的作业，同时在CPU和GPU上运行的CPU+GPU作业，以及其余仅使用CPU的作业。作业的分类基于比较每个节点的平均CPU和GPU功耗。
如果CPU的平均功耗大于250瓦，GPU的平均功耗大于260瓦，我们将作业标记为CPU + GPU作业（同时使用CPU和GPU的作业）。如果GPU的平均功耗超过260瓦，CPU的平均功耗小于250瓦，我们将作业标记为仅使用GPU的作业。剩下的消耗GPU功率小于或等于260瓦的作业被标记为仅使用CPU的作业，包括使用较低CPU功率（即CPU功耗小于250瓦）的作业。以下方程总结了作业被分类为三个类别的情况。
CPU作业：GPU功率≤260瓦
GPU作业：(GPU功率> 260瓦) and (CPU功率≤250瓦)
CPU+GPU作业：(GPU功率> 260瓦) and (CPU功率> 250瓦)
图11显示了三种类别的ML作业（仅使用CPU、仅使用GPU和同时使用CPU和GPU的作业）的GPU功耗与CPU功耗之间的关系，以核密度估计图（KDE）的形式展示。核密度估计图[26]是一种可视化技术，用于显示数据集中观测值的连续概率分布。它类似于直方图，但直方图将数据点分组为离散的区间，而核密度估计使用高斯核平滑观测值，得出连续的密度估计或连续的概率密度曲线。
观察：根据分类，仅使用CPU的ML作业有8294个。仅使用GPU进行计算和处理的ML作业有6291个，而同时使用CPU和GPU进行处理和计算的ML作业有580个。
4.6.2. 基于I/O活动的分类
表8显示了每组ML作业进一步分类为读取密集型、写入密集型和读写密集型的情况。
观察：对于仅使用CPU或仅使用GPU的作业，读取密集型作业的数量大大超过写入密集型和读写密集型的作业。这符合ML作业更多地进行读取而不是写入的普遍观点。然而，同时使用CPU和GPU进行处理的ML作业的读写强度没有明显区别，因此更难以优化。
4.6.3. 基于科学领域的分类
表9显示了基于不同科学领域的ML作业的分类以及它们如何使用处理单元。归类为机器学习领域的作业是来自新提议的专门标记为ML的作业。其他领域的作业具有更传统的HPC工作负载。因此，本节提供了来自ML领域的作业与来自其他领域的作业的比较。
观察：来自生物学领域的ML作业主要使用CPU而不是GPU。然而，计算机科学和物理领域的ML作业使用更多的GPU。标记为机器学习（ML领域）的作业不使用CPU和GPU的组合。它们主要使用GPU，这表明新兴的ML工作负载正在转向更多地使用GPU而不是CPU或两者的组合。
4.6.4. 基于GPFS和BB的分类
如前文所述，仅有四个科学领域，即生物学、化学、计算机科学和材料学，使用BB进行其ML作业。表10显示了基于处理单元使用情况的BB作业的数量。
观察：仅使用GPU的ML作业更有可能同时使用BB进行文件访问。这种使用行为的解释是由于GPU提供的增加处理能力，如果纯粹在GPFS上进行文件访问，将导致更大的I/O瓶颈。
4.6.5. BB作业的I/O性能
我们根据处理单元的使用情况找出BB ML作业的I/O性能。图12显示了BB作业的I/O性能，按照科学领域进行分类，以及对处理单元的使用情况。对于每个科学领域，我们绘制了作业的总体性能，随后是在BB和GPFS上访问的文件的性能。图12(a-b)显示了仅使用CPU的BB作业的读取和写入性能，图12(c-d)显示了仅使用GPU的BB作业的读取和写入性能，图12(e-f)显示了在执行期间同时使用CPU和GPU的作业的读取和写入性能。
观察1：不论处理单元的使用情况如何，生物学和计算机科学领域的BB作业的平均I/O性能更大程度上依赖于BB性能，而来自化学和材料学领域的作业则不然。例如，图12(c)中的生物学BB作业的总体读取性能非常接近从BB访问的文件的性能。相比之下，图12(f)中化学领域的BB作业的总体平均性能与从GPFS访问的文件的性能相似。这种I/O性能上的差异可能与在前面的部分讨论的BB上的读/写模式有关。
观察2：来自材料学和计算机科学领域的仅使用GPU的BB作业在读取和写入方面都比仅使用CPU或同时使用CPU和GPU的BB作业表现出更高的性能。化学和生物学领域的BB作业的I/O性能相似。这表明对于文件访问使用BB和GPU进行处理的作业更有可能获得更好的I/O性能。
4.6.6. GPFS作业的I/O性能
不使用BB而只使用GPFS访问文件的ML作业的读取和写入性能显示在表11中。
观察1：与仅使用CPU或同时使用CPU和GPU的作业相比，仅使用GPU与GPFS结合的ML作业倾向于获得更好的读取和写入性能。这可能是因为将数据预取到GPU内存，这对于使用CPU的作业是不可能的。
观察2：总体而言，读取性能超过写入性能。然而，对于融合和物理学的ML作业，这种趋势并不成立。这可能是因为这两个领域的作业访问的文件大小。大量小读取与大写入可以解释这种行为，这与没有针对I/O进行优化的ML作业的行为相符。
4.6.7. I/O是否真的是ML应用的瓶颈？
在本节中，我们旨在检查I/O是否真的是ML应用的真正瓶颈。首先，我们查看I/O时间占应用总运行时间的百分比。以下是不同类型ML作业基于处理单元使用情况的平均I/O百分比。
CPU作业：1.35%
GPU作业：16.47%
CPU+GPU作业：16.12%
观察1：使用GPU的ML作业通常具有更高的I/O百分比，这表明在GPU上运行的工作负载执行计算部分很快，很可能会产生更高的I/O瓶颈。
接下来，我们看这样的I/O百分比是否会对作业运行时间产生影响。为了回答这个问题，我们选择了一个来自生物学科学领域的应用程序train_cvae。我们选择此应用程序是因为它既在CPU上运行也在GPU上运行。我们还选择了另一个应用程序bert_horovod来展示仅使用CPU的ML作业的行为。结果显示在表12中。我们还观察到对于其他应用程序，I/O时间和作业运行时间也表现出类似的模式，并以train_cvae和bert_horovod作为这些应用程序的代表。在本文中，我们使用这两个应用程序作为例子。然而，这是大多数ML应用程序中观察到的趋势。
观察2：对于相同或相似的数据传输大小并且在相同数量的节点上运行的情况下，使用GPU的ML作业显示出作业运行时间与I/O时间成正比的趋势。然而，对于仅使用CPU的作业，情况并非如此。这意味着I/O性能对于仅使用GPU的作业比仅使用CPU的作业更深地影响作业运行时间。这与流行的观点相矛盾，即拥有更多的GPU会提高ML作业的运行时间。对于更多的GPU，I/O瓶颈可能会产生更大的影响，这意味着I/O优化应与增加处理能力相辅相成。
5. 讨论
对23,389个ML作业（其中15,165个ML作业基于处理单元功耗）的I/O行为分析为未来HPC存储系统提供了有价值的洞察。本研究集中在Summit——全球第二快的超级计算机上的ML作业。然而，本文研究的ML作业也代表了其他领先规模的HPC系统。
最近，一项针对2020年所有Summit工作负载（即传统HPC和新兴ML）I/O行为的研究[27]指出了BB的使用模式。通过将该研究与我们对2020年在Summit上运行的ML作业的研究进行比较，观察到许多领域科学，如物理学和地球科学，使用BB进行传统HPC工作负载，但不使用BB进行ML工作负载。然而，小于1MB的读取和写入调用数量的数量级相同。这显示了传统HPC工作负载使用存储系统的方式与新兴ML工作负载的改进空间。
5.1. 给科学领域专家的启示
来自所有科学领域的ML工作负载产生大量小文件读写，这对BB更合适。然而，只有少数科学领域将BB用于其ML工作负载。因此，领域科学家需要接受培训，以更有效地使用BB进行ML工作负载。
计算机科学领域的HPC ML用户更有效地使用BB，从而获得比其他科学领域更好的I/O性能，而这些领域也使用了BB。观察到计算机科学领域的ML工作负载将读取密集型文件从GPFS复制到BB，并从BB执行大多数读取操作，同时也在BB上进行小写入的突发，后者稍后会持久保存到GPFS。这意味着其他领域科学家也应该接受培训，更有效地使用BB以获得更好的I/O性能。
无论是使用CPU还是GPU，融合和物理学等少数科学领域在并行文件系统中的写入性能优于读取性能。这表明这些ML作业的读取未经过优化，通过优化读取，可以改善这些应用程序的I/O性能，例如通过合并读取或使用BB。
5.2. 给存储架构师的启示
ML工作负载的时间趋势显示，ML工作负载的I/O活动呈指数增长，预示着未来将由ML主导。因此，需要设计更好的存储解决方案，以处理未来HPC ML I/O工作负载的多样化I/O模式。
有时很难修改来自各种科学领域的遗留代码库，以包含对BB的使用。必须开发I/O优化技术，可以在不修改应用程序代码的情况下帮助透明地使用BB。
ML作业的趋势是将处理从CPU转移到GPU，以利用GPU的增加处理能力。然而，我们的研究表明，仅使用GPU的ML作业受到I/O瓶颈的影响更大。因此，存储架构师应该专注于为仅使用GPU的作业开发I/O优化技术，而不是在HPC集群中增加更多的GPU。
本研究还为未来HPC存储系统的容量提供了指导，该系统将由ML工作负载主导。
6. 结论
各种科学领域中ML技术在HPC I/O工作负载中的使用呈指数增长。因此，了解ML工作负载的I/O特性对于系统架构师、文件系统开发人员和HPC用户非常重要。
本文分析了超过23,000个在Summit上运行的ML工作负载的Darshan日志。Darshan日志还与包含处理单元功耗的数据集合并，以获取15,165个ML作业的CPU和GPU使用情况。
我们的研究表明，ML工作负载产生大量小文件读写，这对于Burst Buffer比并行文件系统更为理想。然而，并不是很多科学领域将Burst Buffer有效地用于其ML I/O工作负载。甚至不同规模的作业也影响ML工作负载的I/O使用，只有计算机科学的应用程序使用了Burst Buffer来在超过921个节点上运行作业。这对于领域科学家更有效地使用Burst Buffer进行其ML工作负载，以及存储架构师为未来的大规模HPC存储系统构建更好的存储解决方案提供了经验教训。
我们还注意到在GPU上处理和在BB上进行I/O是获得ML作业最佳I/O性能的理想组合。如果ML作业仅使用并行文件系统，则需要优化读取。同时，我们还观察到仅使用GPU的ML作业比仅使用CPU的ML作业具有更高的I/O瓶颈。
因此，本文为存储架构师提供了关键洞察，为他们构建更好的存储系统优化工具，并为ML用户提供在运行新兴ML工作负载时实现更好。
---【本文完】---
近期受欢迎的文章：
我们正处于数十年未见之大机遇中
新技术爆发式发展，催生新产品
然而，颠覆式创新并非简单的技术堆叠
而是异常复杂的系统工程
需要深度洞察
欢迎一起分享思考和见解
References
[1] N. Naksinehaboon, Y. Liu, C. Leangsuksun, R. Nassar, M. Paun, S.L. Scott, Reliability-aware approach: An incremental checkpoint/restart model in HPC environments, in: International Symposium on Cluster Computing and the Grid, CCGRID, IEEE, 2008, pp. 783–788.
[2] F. Pan, Y. Yue, J. Xiong, D. Hao, I/O characterization of big data workloads in data centers, in: Workshop on Big Data Benchmarks, Performance Optimization, and Emerging Hardware, Springer, 2014, pp. 85–97.
[3] P. Carns, K. Harms, W. Allcock, C. Bacon, S. Lang, R. Latham, R. Ross, Understanding and improving computational science storage access through continuous characterization, ACM Trans. Storage (TOS) 7 (3) (2011) 1–26.
[4] B.K. Pasquale, G.C. Polyzos, Dynamic I/O characterization of I/O intensive scientific applications, in: ACM/IEEE Conference on Supercomputing, 1994, pp. 660–669.
[5] S. Narayan, J.A. Chandy, I/O characterization on a parallel file system, in: International Symposium on Performance Evaluation of Computer & Telecommunication Systems, SPECTS, IEEE, 2010, pp. 133–140.
[6] F. Chowdhury, Y. Zhu, T. Heer, S. Paredes, A. Moody, R. Goldstone, K. Mohror, W. Yu, I/O characterization and performance evaluation of beegfs for deep learning, in: International Conference on Parallel Processing, ICPP, 2019, pp. 1–10.
[7] S.W. Chien, A. Podobas, I.B. Peng, S. Markidis, tf-Darshan: Understanding fine-grained I/O performance in machine learning workloads, in: International Conference on Cluster Computing, CLUSTER, IEEE, 2020, pp. 359–370.
[8] G.K. Lockwood, S. Snyder, S. Byna, P. Carns, N.J. Wright, Understanding data motion in the modern HPC data center, in: IEEE/ACM International Parallel Data Systems Workshop, PDSW, 2019, pp. 74–83.
[9] A.K. Paul, O. Faaland, A. Moody, E. Gonsiorowski, K. Mohror, A.R. Butt, Understanding HPC application I/O behavior using system level statistics, in: International Conference on High Performance Computing, Data, and Analytics, HiPC, IEEE, 2020, pp. 202–211.
[10] H. Luu, B. Behzad, R. Aydt, M. Winslett, A multi-level approach for understanding I/O activity in HPC applications, in: IEEE International Conference on Cluster Computing, CLUSTER, 2013, pp. 1–5.
[11] S. Wright, S. Hammond, S. Pennycook, R. Bird, J. Herdman, I. Miller, A. Vadgama, A. Bhalerao, S. Jarvis, Parallel file system analysis through application I/O tracing, Comput. J. (ISSN: 0010-4620) 56 (2) (2012) 141–155.
[12] Darshan - HPC I/O characterization tool, 2021, https://www.mcs.anl.gov/research/projects/darshan/. (Accessed July 17 2021).
[13] S. Snyder, P. Carns, K. Harms, R. Ross, G.K. Lockwood, N.J. Wright, Modular HPC I/O characterization with darshan, in: Workshop on Extreme-Scale Programming Tools, ESPT, IEEE, 2016, pp. 9–17.
[14] P. Carns, R. Latham, R. Ross, K. Iskra, S. Lang, K. Riley, 24/7 characterization of petascale I/O workloads, in: IEEE International Conference on Cluster Computing and Workshop, 2009, pp. 1–10.
[15] T. Wang, K. Mohror, A. Moody, K. Sato, W. Yu, An ephemeral burst-buffer file system for scientific applications, in: The International Conference for High Performance Computing, Networking, Storage and Analysis, SC, IEEE, 2016, pp. 807–818.
[16] IBM spectrum scale (GPFS), 2021, https://ibm.com/products/spectrum-scale. (Accessed July 17 2021).
[17] Summit, 2021, https://www.olcf.ornl.gov/summit/. (Accessed July 17 2021).
[18] Top 500 - june 2021, 2021, https://www.top500.org/lists/top500/2021/06/. (Accessed July 17 2021).
[19] A.K. Paul, A.M. Karimi, F. Wang, Characterizing machine learning I/O workloads on leadership scale HPC systems, in: 2021 29th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems, MASCOTS, IEEE, 2021, pp. 1–8.
[20] T. Patel, S. Byna, G.K. Lockwood, N.J. Wright, P. Carns, R. Ross, D. Tiwari, Uncovering access, reuse, and sharing characteristics of I/O-intensive files on large-scale production HPC systems, in: 18th USENIX Conference on File and Storage Technologies, FAST 20, 2020, pp. 91–101.
[21] W. Shin, V. Oles, A.M. Karimi, J.A. Ellis, F. Wang, Revealing power, energy and thermal dynamics of a 200PF pre-exascale supercomputer, in:Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, SC, 2021, pp. 1–14.
[22] Summit scheduling policy, 2021, https://docs.olcf.ornl.gov/systems/summit_user_guide.html#scheduling-policy. (Accessed July 16 2021).
[23] A. Kougkas, H. Devarajan, X.-H. Sun, Hermes: A heterogeneous-aware multi-tiered distributed I/O buffering system, in: International Symposium on High-Performance Parallel and Distributed Computing, HPDC, 2018, pp. 219–230.
[24] A. Kougkas, H. Devarajan, X.-H. Sun, I/O acceleration via multi-tiered data buffering and prefetching, J. Comput. Sci. Tech. 35 (1) (2020) 92–120.
[25] Burst buffer on summit, 2021, https://docs.olcf.ornl.gov/systems/summit_user_guide.html#burst-buffer. (Accessed July 16 2021).
[26] B.W. Silverman, Density Estimation for Statistics and Data Analysis, Routledge, 2018.
[27] J.L. Bez, A.M. Karimi, A.K. Paul, B. Xie, S. Byna, P. Carns, S. Oral, F. Wang, J. Hanley, Access patterns and performance behaviors of multi-layer supercomputer I/O subsystems under production load, in: Proceedings of the 31st International Symposium on High-Performance Parallel and Distributed Computing, HPDC, 2022, pp. 43–55.
[28] A.K. Paul, J.Y. Choi, A.M. Karimi, F. Wang, Machine learning assisted HPC workload trace generation for leadership scale storage systems, in: Proceedings of the 31st International Symposium on High-Performance Parallel and Distributed Computing, HPDC, 2022, pp. 199–212.