揭示HPC平台的I/O需求：窥探Santos Dumont的内部机制
Source: AndréRamosCarneiro, Uncovering I/O demands on HPC platforms: Peeking under the hood of Santos Dumont, 18 August 2023
摘要
高性能计算（HPC）平台被要求解决各个研究领域（如生物学、化学、物理学和健康科学）中的大规模科学难题。研究人员使用多种科学软件，这些软件具有不同的要求。其中包括输入和输出操作，由于处理和数据访问速度的差异，这些操作直接影响性能。因此，超级计算机在存储来自应用程序的数据时必须有效地处理混合工作负载。了解在超级计算机中运行的应用程序集以及它们的性能对于理解存储系统的使用情况、确定可能的瓶颈并引导优化技术至关重要。
本研究提出了一种方法和可视化工具，以评估超级计算机的数据存储基础设施性能，考虑了系统在长时间运行过程中的多样化工作负载和需求。作为研究案例，我们着重研究了Santos Dumont超级计算机，识别了低效的使用情况、问题性能因素，并提供了如何解决这些问题的指导。
1. 引言
拥有数百至数千个计算节点的超级计算机主导着HPC环境。这些HPC系统被用于解决各种科学领域中最为多样化的问题，如生物学、化学、物理学和健康科学。不同领域的研究人员使用各种科学软件，这些软件具有不同的要求。例如，应用程序可以是串行或并行的，以不同的格式和大小读/写不同数量的数据。这种情况导致超级计算机必须处理混合的工作负载。
随着处理芯片和高速网络的不断演进，超级计算机现在能够处理更加庞大的数据集。然而，与此同时，存储这些数据集的基础设施也必须提供高性能的数据访问能力，以确保应用程序能够有效地执行其I/O操作。在HPC环境中，影响性能的不仅仅是每秒浮点运算次数（FLOPs）的数量，还包括每秒能够从存储系统中有效读取和写入多少数据。
并行文件系统（PFS）是一种分散的存储系统，其中专用机器充当数据服务器，从而降低了处理I/O请求的开销，它们是HPC系统的事实标准文件系统类型。Lustre [59] 是HPC系统上最常用的PFS之一，在IO500列表 [26] 中代表了约20%的文件系统使用情况。尽管数据存储架构的进步提供了更好的性能，例如通过使用SSD设备，但系统处理I/O操作的速度与处理数据的速度之间仍然存在相当大的性能差距。这种差异影响了超级计算机在为新的科学发现提供有效支持方面的可用性。随着超级计算机的快速扩展以及生成更多需要读取和写入的数据，共享数据存储基础设施成为实现可持续性性能的主要瓶颈之一。由于并发性和干扰的增加 [65]，[66]，PFS已无法持续提供性能。除了I/O操作之外，HPC存储管理中的另一个关键因素是元数据操作，这些操作负责维护文件系统目录树、文件访问权限和所有权、时间戳、属性等。随着数据集变得更大，元数据性能变得至关重要，并可能迅速成为瓶颈 [1]。
Lawrence等人 [35] 表明，不同的科学应用程序受Lustre的影响方式各异，其中一些应用比其它应用更有效地使用资源。影响Lustre性能并限制其性能的一些因素包括不对齐的访问模式 [3]、存储服务器之间的负载不平衡 [48] 和资源竞争 [45]。此外，我们还应考虑到现有的I/O堆栈暴露了大量的可调参数，旨在为不同的工作负载提供性能改进。然而，由于用户对其应用程序的I/O操作了解不足，这些参数的错误配置可能会导致观察到的性能不佳。此外，性能不佳的I/O应用程序还可能对系统中当前运行的所有其它应用程序产生负面影响，因为存储是共享的。
我们的研究旨在通过评估Lustre在不同领域的多样化I/O和元数据工作负载以及其需求方面的性能，来深入探究数据存储对超级计算机的影响。我们研究并比较了两个时期的行为，分别为2020年和2021年的3月至5月，共计三个月的运行时间。在这段时间内，数据进行了高达109,787亿次I/O操作，总计达16.50PiB的数据量。
我们提供了一种可视化性能因素的方法，其中包括小请求大小、负载不平衡以及资源竞争等。为了更具体地展示这些问题，我们以Santos Dumont超级计算机（SDumont）[54] 作为案例研究对象。这是因为对于在这台生产机器上每天运行的应用程序集，以及它们与存储和I/O堆栈配置之间的关系，我们目前所知甚少。
总结而言，我们的研究做出了以下贡献：
我们开发了一种方法来收集、分析和可视化PFS的I/O数据。我们使用了不需要管理员权限的开源软件，使其易于实施和复现。
我们开发了一个Web应用程序，以简化PFS使用数据的可视化和分析。这样的工具使得重新进行分析并研究感兴趣的不同时间段更加容易。
我们调查了Lustre的对象存储目标（OST）和SDumont计算节点的I/O工作负载和使用行为。我们的研究显示，工作负载需求不由单一类型的操作主导，并且在整个时期内可以显著变化。
我们分析了各个OST的使用情况，并在正常系统运行期间显示出显著的负载不平衡。
通过将计算节点的I/O使用指标与作业调度管理系统的信息进行交叉分析，我们能够识别可能导致PFS服务器整体性能降低的问题应用程序。
元数据操作的分析和特征表明存在相当大的需求，其中元数据占所有文件系统操作的60%。
本研究收集的所有数据以及用于分析和可视化数据的工具集均可在附属资料库([9]) 中获得。
本文的其余部分结构如下。第2节将本研究进行了背景说明，并讨论了相关工作。第3节介绍了Lustre的架构和SDumont的基础设施，第4节介绍了我们的方法。结果在第5节讨论。第6节总结了所学到的经验，并将我们的发现与其它系统进行了比较。最后，在第7节中提出了结论性的评论和未来的工作。
2. 相关工作
高效的I/O性能是现代超级计算的关键组成部分。研究表明，需要更好地理解存储基础设施，并通过应用程序解释实现的I/O性能。Huong等人 [42] 分析了来自三个领先的HPC超级计算机平台（ALCF的Intrepid和Mira以及NERSC的Edison）在2014年执行的一百多万个作业的Darshan日志 [10]。作者观察到，四分之三的应用程序的总吞吐量从未超过1 GB/s，约占平均峰值平台带宽的1%。
Lockwood等人 [40] 使用系统监视、基准测试和I/O存储基础设施（Lustre文件系统和GPFS）上的主要HPC中心（NERSC和ALCF）一年的生产运行来识别低性能的原因以及如何提高性能。他们在多个时间尺度上调查应用程序，寻求识别绝对性能和变异性的趋势，数据服务器上的高CPU负载以及带宽争用。结果表明，在正常运行和不同执行期间，I/O性能会发生变化。Wan等人 [63] 采用类似的方法，通过设计一个轻量级的并行测试工具，定期收集在生产HPC系统上运行的应用程序的I/O性能和作业状态跟踪。他们试图将生产HPC系统上不同I/O性能状态之间的转换建模为一个分类问题，并利用该模型来减少争用，同时改善数据访问。
Patel等人 [48] 提出了一种工具，用于分析Lustre PFS的日志数据，这些数据是通过Lustre Monitoring Tool (LMT) [39] 在2018年一年内从NERSC HPC数据中心的并行存储系统（由Edison和Cori超级计算机共享）中获得的。该研究表明，即使在Cori中有一个Burst-Buffer系统，Lustre仍然以读操作为主。
Sivalingam等人 [57] 提出了另一种方法，作者使用LASSi，这是一个分析工具，用于分析在ARCHER超级计算机上部署的Lustre文件系统上由共享资源（文件系统或网络）引起的应用程序使用和争用情况。LASSi将Lustre统计数据和作业信息结合起来，计算派生指标，识别生成过多I/O负载的特定类别的作业。所收集的信息可以用于避免减速，了解共享文件系统中的应用程序I/O行为，并指导HPC文件系统的扩展。类似地，Wadhwa等人 [62] 引入了一个端到端控制平面，以优化I/O资源分配。他们使用用户级库来截取文件I/O调用，并在客户端应用程序中透明地提供运行时优化。他们试图为MetaData Server提供所有资源的应用程序不可知的全局视图。
Kunkel等人 [29] 调查并量化了部署在超级计算机上的共享文件系统的用户感知减速。他们引入了系统性的I/O性能监控，使用探针来导出减速因子。他们评估了三个欧洲HPC系统：英国CEMS的JASMIN、英国NSS的ARCHER和DKRZ的Mistral。为了评估短期干扰，他们在ARCHER上执行了IO-500的标准基准测试MDTest和IOR [25]。他们评估了长达60天的收集统计数据的长期性能影响。在这两种情况下，该方法揭示了系统利用率中的干扰，但仍然缺乏服务器端信息来补充和解释服务器端的性能。
Betke等人[5]旨在通过基于机器学习的工作流程，从作业的遥测数据中识别异常或高负载情况。分析是通过将每个作业的监控数据分割成较小的部分并生成足迹来自动化的。然后，将分类方法应用于足迹数据集，以对具有类似I/O行为的应用程序进行排序，并将具有有害I/O模式的应用程序隔离出来进行优化。他们使用了DKRZ的Mistral监控系统中一周的数据，对8种I/O行为类别的33193个作业进行了分类。尽管是一种有前景的方法，但它需要对自动类别标记进行一些调整。
这些方法依赖于定期执行探测（通常是在共享文件系统上运行的I/O基准测试）、应用程序级别的分析（Darshan）或需要管理员权限的工具。此外，像Darshan这样的性能分析工具通常在这些平台上部署并默认启用，但仍然只覆盖了运行作业的极小部分 [42]，[7]。由于用户可以卸载此模块，并且直到最近，它需要应用程序使用MPI来收集指标，因此需要更多的指标来提供系统的完整图像。我们的研究提出了一种更广泛的方法，以提供系统I/O利用的更大图像，跟踪从存储设备到计算节点的低效行为。我们使用不需要管理员权限的开源软件，使其易于实施和复现。
在HPC存储系统中，元数据性能的问题也受到了广泛关注，这揭示了对改进和更深入理解的需求。例如，Chasapis等人[12]对Lustre文件系统的元数据服务器（MDS）性能进行了评估。研究的结论是，随着插槽数和核心数的增加，并不会实现Lustre元数据性能的相应扩展，因为其软件架构在多核环境中不具备良好的扩展性。此外，他们发现MDS后端设备并不是性能的限制因素，关键问题在于软件架构不适应多核心环境。另一方面，Zhao等人[67]在云计算环境中对四种代表性文件系统（S3FS、HDFS、Ceph和FusionFS）在不同云平台（Kodiak集群、Amazon EC2和FermiCloud）上的性能进行了分析和评估。他们的研究结果表明，采用分布式管理方法比集中部署方式在性能方面带来了数量级的改进，同时展现了几乎线性的可伸缩性（高达512个节点）。
Kunkel等人 [30] 开发了一个名为MDWorkbench的新型元数据基准，能够模拟许多并发用户，提供延迟配置文件和吞吐量。他们用它来评估四个并行文件系统（GPFS IBM Spectrum Scale、Lustre、Cray's Datawarp和DDN IME）在五个计算平台上的性能：ACLF的Cooley、DKRZ的Mistral、Dusseldorf的IME、KAUST的Shaheen II和NERSC的Cori。结果表明，捕捉由元数据更改引起的争用，并识别观察到的吞吐量和延迟之间的关系是可能的。据我们所知，我们的工作是首次将I/O和元数据分析整合在同一方法中，同时对petascale HPC系统的需求进行特征化。
3. Lustre架构及其在SDumont上的部署
在本节中，我们将讨论Lustre的架构以及在SDumont超级计算机上使用的动机。
3.1 Lustre的架构
Lustre PFS是一个完全基于Linux内核实现的开源客户端-服务器文件系统，专为高性能环境而开发。它提供符合POSIX标准的命名空间和可扩展的I/O资源。Lustre不使用传统的基于块的存储，其中文件被分成相等大小的块，并且元数据管理与I/O管理耦合在一起。相反，Lustre使用分布式基于对象的存储，其中文件可以分成不同大小的对象，这些对象存储数据，而元数据管理则被解耦。这种方法将块存储管理委托给专用的后端服务器，从而减少了传统集中式文件系统的可扩展性和性能问题。Lustre上有两种类型的对象：（I）包含字节数组的数据对象，用于存储文件数据，以及（II）包含键值数据的元数据对象，用于实现目录树结构和文件/目录属性。
Lustre的架构的关键组件包括元数据服务器（MDS）、元数据目标（MDT）、对象存储服务器（OSS）、对象存储目标（OST）、客户端和Lustre网络（LNET）。MDS负责管理文件系统上的所有元数据操作，例如决定数据对象将存储在何处，设置和检索文件/目录属性，并将MDT导出给客户端。MDT是负责保存元数据对象的后端存储。OSS处理文件I/O操作，并向客户端导出一个或多个OST，而OST负责存储文件数据对象。客户端将MDT和OST组合在一个单一的文件系统中，同时将用户的请求传达给MDS或OSS。Lustre网络（LNET）提供通信基础设施。
Lustre使用数据条带技术，将文件分成数据块并分配给选定的OST。数据块的大小称为stripe_size，文件将分割成的OST数量称为stripe_count。条带可以提高文件访问的性能，因为它可以聚合多个数据服务器的带宽，使用并行I/O操作来访问单个文件。
3.2 SDumont
位于巴西国家科学计算实验室（LNCC）[44]的Bull/Atos公司制造的Santos Dumont超级计算机（SDumont）[54]是一个具有显著研究多样性的HPC环境示例，涵盖了各个领域的知识，每个领域都具有特定的科学软件集。其中主要领域包括化学（21.3％）、物理学（17.1％）、工程学（12.6％）和生命科学（10.1％）。SDumont是国家高性能计算系统（SINAPAD）[8]的Tier-0，并且是拉丁美洲最大的超级计算机之一。目前有133个研究项目正在SDumont上进行，每天平均有约200个并发作业。自2016年投入运营以来，SDumont总共拥有18424个CPU核心，分布在758个计算节点（CN）上。
为了存储所有数据，SDumont采用了一个通过CRAY/HPE ClusterStor 9000 v3.3部署的共享存储和Lustre PFS，由一个MDS和十个OSS组成。每个服务器都有一个由40个RAID6格式的HDD组成的目标（MDT或OST）。部署系统的总存储容量为1.7PiB。InfiniBand FDR（56 Gb/s）的胖树全非阻塞网络连接了存储服务器和客户端节点。Lustre在客户端节点上挂载，使用默认的stripe_count = 1和stripe_size = 1 MiB。根据ClusterStor 9000的技术规格[24]，具有与SDumont实施的类似特性的Lustre系统应该实现的峰值性能，不考虑缓存效果，为45 GB/s。访问Lustre系统的总体网络带宽为70 GB/s，不应对通信造成瓶颈。
Bez等人[6]研究了MPI实现在执行集体操作时的性能差异，重点关注了SDumont超级计算机上的两个特定应用程序。该研究包括了对初始Lustre工作负载的特征化，使用在一周运行期间收集的监视数据。然而，关于Lustre的行为及其在SDumont上的使用情况仍然没有全面的数据。如果没有在代表性时期内进行详细分析，很难评估Lustre是否提供了所需的性能，或者是否限制了应用程序的可扩展性。
4. 分析和可视化方法
我们提出了一个流程工作流，用于研究超级计算机上Lustre PFS的利用情况。它包括三个步骤，如图1所示：（1）收集来自节点的性能指标；（2）预处理原始指标数据并将其存储在易于使用的格式中；以及（3）分析数据。
4.1 数据收集步骤
我们选择了collectl[13]，这是一个开源的系统性能监控工具，能够从各个子系统中收集指标，如CPU、磁盘、inode、内存和网络。collectl的优势在于它易于部署和配置，不需要管理员特权进行安装或使用，能够将收集的指标存储在本地压缩文件中或通过网络发送，而且具有灵活的API，可以开发定制模块（插件）。collectl-lustre[50]是一个特殊的插件，用于收集Lustre的内核模块在服务器和客户端上公开的I/O指标和元数据计数器。collectl-lustre插件提供的默认I/O指标包括读取和写入操作的数量以及传输的数据量（以KiB为单位）。在接下来的步骤中，会计算附加的指标，总结在表1中。
Lustre的元数据内核模块公开了MDS和计算节点客户端通用的计数器，以及每个客户端专有的其他计数器。因此，collectl-lustre会获取有关MDS和客户端上的fopen和fclose（文件打开和关闭请求）、getattr和setattr（获取和设置文件/目录属性）以及sync（将数据同步到文件系统）计数器的信息。在MDS专有的计数器中，有unlink（文件/目录删除）和statfs（返回文件系统统计信息）。而seek（更改文件指针位置）计数器仅在客户端上可用。
collectl工具版本4.3.1，配备有collectl-lustre，已安装在所有ClusterStor Lustre节点（包括MDS和OSS节点）以及758个计算节点上。我们将收集到的指标每日压缩存储在本地的/tmp文件系统中，以避免与Lustre产生干扰。collectl对被监测节点所施加的额外负担几乎可以忽略不计（<0.1%的CPU使用率）。在预处理和分析步骤期间，短时间间隔内的数据收集会对存储空间和CPU资源产生显著的需求。因此，我们每15秒收集一次Lustre利用率指标。我们最初的评估考虑了1秒的时间间隔。然而，我们注意到对于单个节点，collectl每天会生成一个超过1 MB的文件。考虑到系统中的756个节点，每天需要约760 MB的存储空间，一个月下来将产生约21 GB的指标数据。相比之下，当将时间间隔增加到15秒时，我们观察到每月文件大小约为1.5 GB，降低了14倍。尽管会失去一定的精度（因为collectl会在该时间间隔内提供平均值），我们发现这个选择仍然能够为我们提供系统利用率的整体良好图像。
4.2 数据预处理步骤
collectl生成的文件每天从每个节点收集一次，然后进行预处理，包括解析、清理和将数据插入到SQLite[58]数据库中。选择使用SQLite格式存储数据是因为它的便携性（数据库是单个紧凑文件，任何存储在其中的数据集都可以轻松地从一个系统转移到另一个系统），并且它在大多数Linux发行版上都预安装了。此外，它还具有各种数据分析工具和编程语言的API。我们有两个不同的数据集，一个来自ClusterStor节点收集的数据（图2a和2b），另一个来自SDumont基础计算节点的数据（图2c和2d）。
仅从计算节点收集的数据并不能提供足够深入的洞察，以全面了解使用Lustre文件系统的情况，涵盖了“谁、如何以及为什么”。因此，在这项研究中采用了一种中间数据的交叉处理方法，将不同来源的数据相互结合起来。这些数据源包括：（1）计算节点数据集，（2）由SLURM1资源管理器提供的关于已提交作业的数量、应用程序名称、运行时间、开始和结束时间、计算节点数量以及总核心数的数据，以及（3）SDumont管理团队使用的内部管理数据库中的信息。通过将交叉引用的作业节点数据、作业所属的科学领域以及计算节点数据集中的性能指标进行整合，生成了一个全新的时间序列数据集，称为作业使用情况数据集（如图2e和2f所示）。图2展示了数据集的结构，除了之前提及的指标外，还包括了时间戳（Timestamp）用于指示数据收集的时间点，OST名称（OST Name）表示进行I/O操作的对象存储目标的名称，节点名称（Node Name）表示使用Lustre PFS的计算节点的名称（无论是通过OST进行I/O操作还是通过MDT进行元数据操作），作业标识号（jobid）用于标识在计算节点上使用Lustre PFS的特定作业，账户名称（account）表示提交作业的Linux组名称，科学领域名称（Science Domain）表示与账户相关联的科学领域，应用程序名称（application）表示已提交作业所使用的应用程序名称。
在这一步中，还在预处理阶段生成了两个互补的I/O指标：（I）平均块（传输）大小（以KiB为单位）和（II）操作质量（QO），如Sivalingam等人[57]所提出的。后者基于SDumont上Lustre文件系统的默认1 MiB条带大小。基于QO，当至少读取或写入1 MiB时，操作将对Lustre进行最佳使用。因此，“1”的值表示最佳使用，而数量级更高的值表示质量较差的使用。
4.3 数据分析步骤
在这一步骤中，还会计算额外的特征：带宽覆盖因子（CFbw）、负载不平衡（LI）以及每个指标的简单移动平均（SMA）。带宽覆盖因子CFbw（1），正如Loockwood等人[40]提出的，表示可以归因于作业的系统带宽的比例，由作业传输的数据量除以传输到/从Lustre的数据量。例如，具有CFbw值为0.60的作业表示其他竞争作业消耗了可用资源的40%。
标准差（σ）衡量了值的分布在中心趋势方面的离散程度。考虑到OST的负载（每个时间戳读/写的数据量），可以使用σ来评估负载不平衡的严重程度。σ为零意味着负载均匀分布。当分布呈现“高”σ时，少数OST处理的数据量比其他OST多。相反，“低”σ表示负载分布更均匀。由于σ是根据每个时间戳上OST上观察到的平均（μ）负载而量化的，因此我们定义了LI = σ/μ指标，作为一个变异系数，更好地表达不平衡的严重程度。LI值低于0.5可以被认为是低不平衡，值在1左右为中等，而高于1的值被视为严重不平衡。
简单移动平均（SMA）[23]，是一种常用于金融市场的时间序列分析技术，它是在特定时间范围（tf）内变量的算术平均值，并且在时间序列中移动。对于时间戳t处的度量m，m的SMAtf由以下公式给出：
金融市场数据随时间变化很大，类似于HPC上的I/O使用情况。通过使用SMA，可以在一段时间内识别出趋势。我们测试了许多时间框架间隔，并选择使用3小时，证明这是一个合理的长度，可以减少高变异性和数据量带来的“噪音”，同时仍然提供良好的表示。
要使用SDumont或其它HPC平台的新数据集对此研究的分析进行复制可能是令人生畏的。为了简化分析过程，我们使用Shiny [55]开发了一个Web应用程序。该应用程序使用第2步生成的数据集，并为任何感兴趣的时间范围生成统计和可视化分析，从而方便结果的复现。这个研究中使用的应用程序的精简版本可以在http://arcarneiro.shinyapps.io/sdumont_lustre上公开访问。运行研究中使用的完整版本应用程序的要求是拥有Shiny Server的系统、100 GiB的存储空间、16 GiB的RAM和四核2.20 GHz处理器。
5. 审视Lustre文件系统
我们收集了2020年和2021年三个月（3月、4月和5月）的使用指标，以研究SDumont上Lustre PFS的利用情况，并比较两年之间的发现。对PFS的分析分为两个部分。首先，我们使用ClusterStor数据集（第5.1节）分析了整个期间（三个月）。其次，我们使用作业使用数据集（第5.2节）关注了一个特定的感兴趣期间。在每个部分中，我们比较了两年的数据，以评估PFS利用情况的演变。
5.1 Lustre使用情况概述
在本节中，我们提供Lustre PFS利用情况的概述，分析了2020年和2021年3月、4月和5月期间获得的操作数据。在第5.1.1节中，我们着重分析了使用ClusterStor的OSS和OST收集的数据系统上执行的I/O操作。在第5.1.2节中，我们评估了使用MDS数据的元数据操作。
5.1.1 I/O数据分析
我们调查了存储系统在上述时期的聚合吞吐量。图3以GiB/m为单位分别显示了2020年（左侧）和2021年（右侧）的结果。根据收集指标的时间，读取（红色）和写入（蓝色）操作被堆叠在一起。在这两年中，ClusterStor进行了定期维护，以恢复故障节点并更新Lustre版本。2020年，维护窗口是从4月13日到4月17日，而2021年是从3月8日到3月12日。在这些时间段内，文件系统是不可访问的，因此没有报告的值。
比较两年的数据，可以注意到利用率有所增加。就绝对数值而言，在2020年，读取了1.8 PiB的数据，写入了2.9 PiB，并且系统接收了641.54亿次读取请求和12.34亿次写入请求。与2021年相比，数据读取的总量增加了4.7倍（7.95 PiB），写入的数据增加了1.5倍（4.1 PiB）。读取操作的数量减少了1.6倍（391.02亿次），写入操作增加了4.3倍（52.97亿次）。数据传输量的增加伴随着提交给SDumont的作业数量的增加，在2020年有36884个作业，在2021年有145793个作业，表示作业增加了4倍。数据读取量的增加但操作数量的减少表明应用程序正在读取更大块的数据，这有助于实现高性能。然而，写入操作似乎朝着相反的方向发展，请求的大小较小，这已被证明会损害性能[33]，[27]。
在收集的数据的整个期间内，并考虑整个文件系统（所有OST的总和），无论是在2020年还是2021年，各种操作中吞吐量的最高峰值都归因于写操作。2020年的最高峰值为1127 GiB/m（在2020年4月20日14:30:00）；2021年的最高峰值为1145 GiB/m（在2021年4月1日18:50:00），分别相当于ClusterStor的最大带宽的约41.74%和42.41%。2020年的平均写吞吐量为25.336 GiB/m，2021年为34.452 GiB/m（增加了1.3倍）。2020年的读操作呈现较低的值，但在2021年有显著增加。2020年的最高吞吐量为316 GiB/m（在2020年3月24日20:36:00），2021年为1077 GiB/m（在2021年3月20日18:50:00），分别占最大带宽的约11.7%和39.89%。2020年的平均读吞吐量为15.825 GiB/m，2021年为66.953 GiB/m（增加了4.2倍）。如果我们关注每个OST注册的吞吐量峰值，写操作发生在所有OST上的同时，这是整个文件系统的吞吐量峰值。另一方面，读取在每个OST上的峰值在一段时间内分散开来，没有任何OST的峰值重叠。这种行为表明应用程序在写入数据时比读取数据更加协调。
表2描述了两年内观察到的操作大小和操作质量的分布情况，表明在2020年，写入操作更有效地使用了Lustre文件系统，75%的操作在2 QO以下，并使用较大的请求大小。另一方面，读取操作显示出相对低效的使用，大部分操作在2 QO以上，并使用小于512 KiB的请求大小。在2021年，与写入相比，读取仍然是相对低效的，并且在传输的数据量方面较小。尽管如此，当将2020年的读取操作与2021年的值进行比较时，仍然可以注意到显着的改进。例如，中位数读取传输大小从23 KiB增加到816 KiB。读取操作大小的增加是造成读取操作数量减少但传输的数据量增加的原因。写入操作显示出轻微的下降（质量较低且传输大小较小）。表2中的另一个重要观察结果是，在2021年，读取和写入操作之间的性能差距缩小了。在2020年，平均写操作大小约为读取大小的3倍（分别为1729 KiB和651 KiB），而在2021年，写入大小仅为读取大小的约1.4倍（分别为1488 KiB和1018 KiB）。请求大小的差异解释了为什么我们观察到写入操作的吞吐量更高。
至于工作负载特性，我们分析了每种类型的操作对系统的需求量。总体而言，2020年写入工作负载主导了吞吐量，占所有数据传输的61.75%。然而，考虑到操作的数量，工作负载主要由读取操作主导，占总数的98.11%。读取操作的数量比写入多约52倍。2020年的数据呈现出这样一个情景，即Lustre收到了大量低效的读取。2021年，读取操作主导了两种工作负载，占吞吐量的66%，操作数量占88%。
图4的左侧描绘了从2020年3月10日开始，按周分组的读取和写入工作负载分布情况，并按操作数量（上部）和传输数据量（下部）进行分割。检查点并不总是主导HPC系统的I/O工作负载。作为科学研究的一部分，科学家正在将大量数据读入HPC系统[41]，[34]。随着来自大数据和机器学习的新应用进入HPC系统，基于平台上运行的应用程序集，读取和写入工作负载之间的比例会有所变化。总体而言，在三个月的观察期内，12个星期中有9个星期的数据传输由写入操作主导。尽管如此，在三周内（W14、W16和W17），这一趋势转向了读取密集型应用。就操作数量而言，工作负载在所有周内都由读取操作主导，在W12上平衡较好。图4展示了I/O操作需求在这段时间内的变化以及工作负载的多样性——尽管出现了更多的读取操作，但也正在写入更多的数据（特别是在最后五周）。
与2020年不同，图4中的右侧部分表示2021年数据传输的数据量由读取主导，只有14个星期中的四个星期由写入主导。大多数周的读取操作数量仍然主导，除了W10和W11两周，这两周的操作数量和数据传输量都由写入主导。同样的行为（大量小规模读取操作）仍然存在，特别是在W15和W17两周，其中读取操作主导了操作数量，但写入操作主导了数据传输量。这促使系统管理员、I/O库开发人员和I/O专家为读取密集型和写入密集型应用程序采取自动选择性优化，考虑到应用程序在未来超级计算机的I/O子系统中的I/O需求和特征。
OST的负载分布分析表明存在显著的不平衡。图5（左侧）显示，在2020年，关于负载不平衡的读取和写入操作都遵循类似的趋势。尽管ClusterStor在50%的时间内的负载不平衡为0.6，但也存在一些严重情况，负载超过OST平均负载的300%。一个有趣的不平衡情况发生在4月10日，可以观察到写入负载的突增。不仅不平衡性严重，而且在某些情况下持续了一天以上。2020年读取平均值为0.92，而写入平均值为0.80。在读取和写入之间的不平衡程度相似，至少有25%的时间使用不平衡度超过1。
Lustre的默认负载平衡侧重于OST的可用存储空间，其中MDS使用循环分配方法来指定数据对象的存储位置。这种方法不考虑OSS上的当前I/O负载，并且与SDumont上的默认条带策略（stripe_count = 1和stripe_size = 1MiB）结合使用，可能会导致热点和资源争用，从而降低性能。因此，通过在机器上更新默认的分条策略，可以更好地在所选的OST之间分布负载，从而减轻这种不平衡。系统管理员可能采取的另一种更具侵入性的方法是采用动态负载平衡器，该负载平衡器可以自动协调I/O服务器之间的工作负载和数据放置，从而实现更好的负载均衡[45]，[62]。
图6描述了从2020年获得的读取和写入吞吐量SMA3HR（方程（2）），按OST进行了分解。4月10日不平衡的峰值是因为OST 09承受了更大的写入工作负载。使用SMA，我们可以观察到一般趋势，识别出使用峰值发生的位置以及特定OST在其它OST之前接收更多负载的时间段。
图5（右侧）描绘了2021年利用率数据中不平衡的减少，2021年读取的平均LI为0.68，而写入为0.58。读取更不平衡，至少有25%的时间使用LI超过1。在3月28日至4月5日期间（也可以在图3中观察到读取增加），读取的LI增加，主要是在三个OST（01、03和08）上的负载集中造成的。
5.1.2. 元数据分析
本小节介绍了对2021年数据集上Lustre PFS执行的元数据操作的分析。由于collectl插件MDS模块的一个错误，我们无法在2020年收集一些指标，该错误阻止了对Lustre MDS内核模块的较新版本（2.10及更高版本）暴露的正确操作计数器信息的收集。
表3总结了整个时期内每种元数据操作的执行情况。最具要求的操作是fopen、fclose、getattr和setattr。在同一时间戳下考虑所有执行的元数据操作，平均每秒操作数为8920，最大值为每秒操作数205016。似乎用户倾向于将Lustre PFS视为常规文件系统，例如HOMEDIR，在这里他们通常执行返回文件和目录属性（大小和访问模式）的大量命令。这种行为可能会对MDS产生不必要的负担，因为这个操作是昂贵的（MDS必须查询每个OST以获取关于对象大小的信息以获得总文件大小）。setattr操作与文件创建相关，因为我们配置了默认的访问模式。另一方面，用户通过chmod或chown命令手动更改文件属性的情况并不常见。另一个显著的行为是文件移除（unlink）的“低”数量。这表明许多旧的未使用文件占用了Lustre PFS上的宝贵空间。
图7A描述了I/O和元数据操作之间的负载分布情况。可以注意到，元数据操作主导了大多数周，除了W12和W13。这个图表显示了在SDumont上利用Lustre PFS的元数据密集型使用情况，其中I/O操作仅占总负载的5%。元数据占所有文件系统操作的60%，约为670亿次请求，而I/O请求约为440亿次。在图7B中，可以观察到整个时期内fopen和fclose操作的大致恒定趋势。然而，在W10上，getattr和setattr操作有所增加，这也在W17、W18和W19上观察到。该系统需要大量打开和关闭文件以及检索文件或目录属性的操作。大多数时间，打开和关闭文件的操作数量要多于读取和写入操作，这表明系统处理许多小文件，并且应用程序执行小吞吐量的I/O（如第5.1.1节所示）。在SDumont上表征的元数据工作负载对于高吞吐量的scratch Lustre PFS来说并不理想。
元数据操作正在成为高性能存储的一个越来越热门的发展课题，也是一个真正的关注点。可以在最新版本的IO500 [31]中观察到这一趋势，在最大分数的最大增长中，元数据的增长最为显著，而I/O吞吐量在多年来几乎没有增加。提高元数据性能的改进包括使用多个服务器[53]、索引机制[49]和客户端预分配[37]。还有一些特定于改善Lustre元数据性能的功能[18]，系统管理员应该进行评估，例如分布式命名空间（DNE-使用多个元数据服务器来分布负载）和元数据上的数据（DoM-将小文件存储在MDT上，显著减少请求和对OST的访问）。在SDumont上并没有实施这些改进。
5.2. 重点领域的详细分析
第5.1节提供了SDumont上Lustre PFS使用情况的总体视图，指出读取操作似乎对PFS的使用效率不高，并且具有较高的元数据操作需求。为了进行更深入的分析，我们选择了两个时段，分别来自每年的一个时段，以使用Job Usage数据集进行分析，以验证哪些应用程序对特定事件做出了贡献。从2020年，我们选择了3月24日到3月28日的时段，因为它包含了读取操作的峰值吞吐量（图3左侧）；从2021年，选择了3月28日到4月1日的时段，因为读取容量显著增加（图3右侧）。根据计算节点数据集和SLURM的作业列表交叉信息在资源上要求很高，取决于日期范围。尽管如此，这个过程可以按需在任何时段执行，以更好地了解Lustre FS在给定事件期间的行为。
5.2.1. 应用程序 I/O 数据分析
在本小节中，我们使用在计算节点收集到的信息来对应用程序的 I/O 利用进行特征化。在选定的2020年时期内，共有866个作业在 SDumont 上执行。通过 SLURM 的信息，我们能够识别出九种不同的应用程序：AMBER [60]、BIE [64]、CASINO [11]、DockThor [15]、GROMACS [21]、LAMMPS [32]、NAMD [43]、QUANTUM ESPRESSO [52] 和 SIESTA [56]。我们无法仅通过 SLURM 提供的可执行文件名单独识别出某些作业的应用程序，因此将它们分为三组进行分类，分别为 Bash 脚本（执行的可执行文件名为 bash，用户的作业是直接通过脚本执行的）、OpenMPI mpiexec（执行的可执行文件名为 orted，应用程序是直接通过 mpiexec/mpirun 启动的，而不使用 SLURM 的 srun 命令）和未知（当用户编译应用程序并且提供的可执行文件名在已知应用程序数据库中不存在时）。
图8详细描述了这些应用程序以及哪些“科学领域”使用了它们。有趣的是，一个应用程序可以被不同领域使用，例如 GROMACS，被化学、物理、生物科学和健康科学等多个领域使用。这个事实导致应用程序具有不同的 I/O 体积、需求和行为 [6]。使用最多应用程序集的科学领域是物理学，共有九个不同的应用程序，其次是化学，有五个应用程序。2020年执行次数最多的五个应用程序分别是未知（37.41%）、DockThor（27.83%）、QUANTUM ESPRESSO（9.93%）、AMBER（7.39%）和 Bash 脚本（6.93%）。对于2021年的数据集，我们观察到总共提交了845个作业，记录了十一个不同的应用程序（以及三个组）：AMBER、BIE、DockThor、GROMACS、LAMMPS、LHCB DIRAC [36]、ORCA [47]、Python [51]、QUANTUM ESPRESSO、SIESTA 和 VASP [61]。使用最多的科学领域是物理学和化学，它们分别使用了七个不同的应用程序。2021年执行次数最多的五个应用程序是：DockThor（36.21%）、未知（17.75%）、QUANTUM ESPRESSO（10.06%）、LHCB DIRAC（8.88%）和 AMBER（7.57%）。
存储系统可以采用不同类型的优化来提高性能。I/O 优化可以应用于堆栈的每个层次中的应用程序 [4]，自动动态调度程序 [19]、[16] 可以调度具有相同 I/O 模式的应用程序以减轻拥塞。这些优化技术共同需要的一点是每个应用程序的 I/O 访问模式特性。同一个应用程序可能具有不同的 I/O 行为 [6]，这取决于它所用于的科学领域。因此，了解使用应用程序的科学领域的信息以及访问模式可能有助于 I/O 库、调度程序和其它技术在应用优化时获得更好的图片和理解。
除了在2020年实现的读取的最大吞吐量（在第5.1节中介绍），此特定时期写入的最高峰值为370 GiB/m（于2020年3月27日）。表4描述了个别应用程序在读取和写入方面实现的最高峰值。需要注意的是：（I）仅有一个作业（应用程序）在2020年期间占据了约91.87%的读取吞吐量和约95.43%的写入吞吐量，（II）二者的CFbw都很高，（III）从2020年到2021年，个别应用程序的吞吐量减少，但更多应用程序的带宽利用率增加（CFbw值减少）。QUANTUM ESPRESSO可以归类为传统的高性能科学应用程序，高度并行化和优化[20]。
图9展示了整个Lustre文件系统带宽的使用情况，其中绘制了特定2020年时段内每个时间戳的作业的最大值（红色）、最小值（蓝色）和平均值（黑色）的CFbw。该行为表明，一些具有高I/O吞吐量的应用程序占用了带宽，因为平均值接近于最小值。
如图10所示，2021年也有少数几个作业占据了带宽。我们观察到高带宽的作业从5月31日开始，最大CFbw值下降，平均值略有增加。
图11呈现了2020年的整体传输大小和QO指标的分布情况。我们分析了每个应用程序的操作质量分布情况，其中大多数应用程序的读取效率较低，readgo大多数时间都在1以上。在2020年，最明显的读取效率低下的应用程序是DockThor、BIE和Bash脚本。只有OpenMPI mpiexec类别在其执行的75%时间内的readgo值低于1，这意味着它读取的数据块更接近Lustre的stripe_size。关于每个科学领域，生物多样性和材料科学表现出最佳的行为，使用较大的操作大小并具有良好的QO指数。
至于传输大小，大多数应用程序很少使用大于1 MiB 的大小。大多数情况下，至少有 75% 的操作使用 100 KiB 或更小的大小。我们没有观察到大于 4 MiB 的传输大小，这是因为 Lustre 默认的客户端到 OST 的最大批量 I/O RPC 大小 [46]，即使应用程序可能正在发出更大的操作。大于 4 MiB 的请求需要通过两个或更多的 RPC 进行拆分。在当前 Lustre 版本（2.1X）中，这个参数可以调整到最大 16 MiB，允许更少的 RPC 在客户端和服务器之间传输相同数量的数据。使用更大大小操作的应用程序包括 SIESTA、QUANTUM ESPRESSO、CASINO 和 AMBER，至少有 50% 的时间内传输大小大于 1 MiB。传输大小最大的类别是 OpenMPI mpiexec，其在其执行的 75% 时间内使用 2 MiB 以上。传输大小最小的应用程序是 LAMMPS、DockThor 和 Bash 脚本，它们的操作有 75% 的时间内小于 40 KiB。
应用程序在2020年的工作负载主要由写操作主导，无论是操作数量还是数据传输量。同样地，只有 OpenMPI mpiexec 类别在操作数量和数据量方面呈现出读取主导（读取数量超过操作数量的80%，数据量也是如此）。两个应用程序呈现出相反的工作负载需求：（I）CASINO，读取操作的数量受主导，而数据传输受写操作的主导（这表明其写操作大于读操作）；（II）BIE，写操作主导操作数量，而读取操作主导数据传输（这表明其读操作大于写操作）。关于每个科学领域的工作负载，有五个科学领域的读取数量占主导地位，其中最明显的是生物多样性（90%）和健康科学（76%）。在考虑到传输的数据量时，只有生物多样性的工作负载以读取为主导（55%）。在操作数量和数据量方面，最需要写入的领域是地球科学、生物科学、气候和天气。有两个有趣的情况是天文学和健康科学，其中读取操作主导操作数量，但数据传输的数据量由写操作主导，这表明这两个科学领域的工作流程利用了许多小型读取操作和少量较大的写入操作。
2021年时期的数据显示，读取密集型应用程序的数量有所增加，在识别出的十四个应用程序中，有四个应用程序（BIE、OpenMPI mpiexec、Python 和未知）在操作数量和数据传输量方面都以读取为主导。ORCA 在操作数量方面呈现出读取密集型工作负载，但写入的数据量更大，两种操作的传输大小差异显著 - 虽然读取操作的75% 传输大小低于45 KiB，但写入操作的传输大小在75% 的时间内高于1 MiB。Bash Script 的数据传输以读取为主导，但发出的写入操作更多，表明存在许多小型写入（75% 的时间内小于 2 KiB）。其它应用程序都以写入为主。
观察2021年中数据传输最密集的五个应用程序时，未知组（第二高执行次数）平均每个作业读取的数据量最大（5394 GiB - 但每个作业只写入 23 GiB），这是在 Fig. 3b 中观察到的读取活动的显著增加的原因。BIE 是第二个应用程序，平均每个作业读取了 793 GiB，写入了 60 GiB 的数据。接下来的应用程序是 OpenMPI mpiexec（95 GiB 和 42 GiB）、AMBER（3 GiB 和 44 GiB）以及 QUANTUM ESPRESSO（2 GiB 和 22 GiB）。有趣的是，没有一个应用程序呈现出平均的读取/写入工作负载。
最后，我们通过在每个时间戳处使用在计算节点收集到的数据来评估每个应用程序执行的 I/O 并行性水平。我们从两个方面分析：（1）使用了多少个 OSTs，以及（2）执行 I/O 操作的计算节点数量。在2020年，每个应用程序平均同时使用的 OST 数量约为 3.24，这低于可用的 OST 数量（总共有10个）。在 75% 的时间内，应用程序仅同时使用了最多四个 OSTs。在进行 I/O 活动时，平均同时使用的计算节点数量为约 1.64，而在 75% 的情况下，仅使用了最多两个节点，这相对于所使用的 OSTs 要少得多。这种比例上的差异表明，大部分时间内，应用程序使用少量计算节点在更多的 OSTs 上执行 I/O 操作。事实上，我们观察到有些情况下，应用程序只使用一个计算节点在所有十个 OSTs 上进行写入。
2021年的并行性水平遵循与2020年相似的趋势，平均同时使用的 OST 数量为 3.6，而用于 I/O 操作的计算节点平均数为 1.65。通过按操作类型划分的利用率分析显示，平均而言，作业使用约 4 个 OSTs 进行并发读取。写操作显示出略低的值，平均同时使用的 OST 数量为 3.3。总体而言，应用程序在 I/O 操作中使用的同时节点数比可用的 OSTs 数量要少，只有五个应用程序同时使用了五个或更多的计算节点。
通过分析应用程序在 SDumont 上如何使用 Lustre PFS，我们能够确定大多数应用程序进行小型 I/O 请求，特别是读取操作，从而导致效率低下的利用。小请求的高比例表明，大多数应用程序未使用专门的 I/O 库（例如 HDF5 [17] 和 MPI-IO [14]），这些库具有优化功能，可以聚合和重新组织数据访问模式，以读取或写入大块连续的数据，以实现与存储服务器中的布局相匹配。正如带宽的覆盖系数（Fig. 9、Fig. 10）所示，少数发出高吞吐量操作的应用程序使用了存储系统提供的大部分聚合带宽，留下了大量可用资源。另一方面，对于低延迟性能的需求相当大，以响应许多小型传输大小操作。我们认为，I/O 转发 [2] 或 Burst Buffer [38] 层将显著有助于处理这些低延迟的小型请求。系统管理员可以选择将精力投入到改进最需要的应用程序的 I/O 性能，或者实施框架 [4]、[19]、[16]，为更广泛的应用程序自动调整和优化 I/O。
5.2.2. 应用程序元数据分析
在这个小节中，我们使用在计算节点上收集的信息来描述在第5.2节中定义的时间段内应用程序的元数据利用情况。图12A展示了在2020年窗口中执行的每个应用程序作业记录的I/O和元数据操作之间的负载比例。在识别出的十二个应用程序中，只有CASINO表现出了元数据密集型行为（元数据比I/O多）。AMBER也大量使用元数据。元数据使用最低的是GROMACS、LAMMPS和OpenMPI mpiexec类别。可以注意到通常的元数据操作负载在10%到25%之间。
图12B描述了应用程序使用的元数据操作类型。可以观察到寻址操作在大多数应用程序（AMBER、Bash 脚本、CASINO、NAMD、QUANTUM ESPRESSO、SIESTA 和未知）中占主导地位，表明存在大量的随机文件访问。两个应用程序（BIE 和 OpenMPI mpiexec）呈现出大量的 fopen 和 fclose 操作，表明在其工作流程中使用了许多文件。三个应用程序（DockThor、GROMACS 和 LAMMPS）呈现出大量的 getattr 操作，这些操作从 MDS 检索文件信息，应尽量避免，以减少 MDS 的负荷。应用程序几乎不使用 setattr 操作。这些观察结果强调了共享 PFS 必须有效处理的异质 I/O 工作负载。然而，丰富的可调参数使终端用户很难理解何时以及如何调整它以避免瓶颈。此外，由于其共享性质，调整不良的应用程序可能会损害它们自己和其它并发作业的性能。未来的 HPC 存储系统应自动隔离这些问题，或者提供基于观察到的 I/O 工作负载的调整机制。
关于科学领域，只有材料科学和天文学是元数据密集型的，它们的负载分别达到55%和49%。健康科学对元数据操作的使用很少，呈现出最低的工作负载。其它领域的元数据负载在10%到25%之间。
我们省略了来自2021年数据的元数据负载分布图，因为大多数在2021年期间识别出的应用程序也出现在2020年，并且其特征相似（该图可在伴随存储库 [9] 中找到）。对于在2021年期间识别出但不在图12中的应用程序，只有Python和LHCB DIRAC表现出元数据密集型行为，其负载分别为95%和65%。ORCA 和 VASP 是I/O 密集型的，其元数据负载仅为5%。关于每个应用程序最常使用的元数据操作，LHCB DIRAC由寻址和 getattr 主导，ORCA 有大量的文件打开和关闭操作，Python 由 getattr 执行主导，VASP 则有大量的寻址操作。
6. 讨论
在本节中，我们将总结所获得的教训，并将SDumont上的Lustre PFS部署与其他HPC平台的存储系统进行比较。
I/O工作负载：在HPC系统上，I/O工作负载并不被单一类型的操作主导，这与多项研究结果一致。虽然Kim等人[28]指出读取（42.2%）和写入（57.8%）工作负载之间只有微小的差异，Gunasekaran等人[22]的分析则显示75%的工作负载由写入操作主导。另一方面，Patel等人[48]观察到读取一直在主导工作负载。我们在SDumont上的观察结果显示，数据传输量呈现出一定的季节性变化（图4）。在2020年，上半年以读取操作为主，而下半年则以写入操作为主。然而，无论请求数量如何，工作负载主要受到读取操作的影响。总体而言，总数据写入量约为读取数据的1.6倍，但系统收到的读取请求数比写入请求多约52倍。这表明更多的数据是以大的请求大小进行写入的。我们的发现有助于设计未来的HPC系统存储系统采购策略，尤其适用于具有异构环境的系统。
数据请求大小：Kim等人[28]的研究发现，大多数请求大小要么小于16 KiB，要么在512 KiB到1 MiB之间。然而，Gunasekaran等人[22]得出结论，60%的写入请求大小为4 KiB或更小，超过50%的读取请求大小至少为1 MiB。与之不同的是，在SDumont上，请求大小的比例是相反的，读取请求很小（50%在23 KiB以下），而写入请求较大（50%达到约1.5 MiB）。SDumont上的写入操作大小约为读取操作的3倍。这种操作大小的差异证实了相比写入操作，存在更多的小读取操作。在操作质量方面，读取操作的表现也明显较差。这些信息有助于优化块设备，因为PFS的吞吐量在很大程度上取决于请求大小。
带宽利用：与其他系统相比，SDumont的带宽利用率较低。Kim等人[28]观察到的最大读取吞吐量达到最大带宽的75%，而写入吞吐量达到54%。Gunasekaran等人[22]所分析的系统呈现出高达80%的读取带宽和70%的写入带宽。而在SDumont上，写入操作的带宽峰值仅达到最大带宽的41.74%，而读取操作的带宽峰值仅达到11.7%。除了较低的带宽利用率外，我们还观察到了相反的趋势。读取操作的性能较差，这是因为其请求大小远小于写入操作。
负载不平衡：负载不平衡仍然是大规模平台尚未完全解决的问题。正如我们的结果所示（图5），SDumont上的负载不平衡可能会严重到某个单独的OST接收100%的负载。之前的研究（[28]，[48]）也报告了类似的问题。高度不平衡的负载会导致低吞吐量和低利用率。为了缓解这个问题，系统管理员可以考虑采用动态负载均衡器，自动协调I/O服务器之间的工作负载和数据放置。
低I/O并行性：HPC应用程序仍未充分利用PFS或那些具有提升I/O性能潜力的高级I/O库和中间件。在SDumont上，观察到75%的作业仅使用了最多4个可用OST中的10个。这也是带宽利用率低的另一个指示。应用程序开发人员应该考虑使用高级I/O库来利用数据访问的并行性，而终端用户则应该获得指导，了解如何调整文件系统的分片参数以实现更高效的使用。
7. 结论
本研究对SDumont超级计算机的存储系统进行了评估，该计算机承载了来自不同科学领域的研究。我们收集了数据指标，并在两年内的三个月内分析了该机器的I/O行为。我们提出的方法为深入理解Lustre的使用提供了洞察。我们成功地识别出对SDumont性能产生负面影响的关键因素：
低效的读取操作：存在大量使用小传输大小的操作，通常导致性能下降。这还表明应用程序未能充分利用高级I/O库和中间件将小请求合并为较大请求。
资源不平衡：通过个别OST使用情况的视图，我们能够评估负载的分布情况，发现了一些严重且持久的情况，其中超负荷情况相当于平均OST负载的3倍。
问题应用程序：我们成功地识别出一些问题行为，例如BIE，其表现出最差的readgo值，并且数据传输工作负载主要由读取操作所主导。
对元数据操作的需求：元数据分析显示SDumont对这种类型的操作有相当大的需求，占所有文件系统操作的60%。这种情况对系统管理员发出警告，需要迅速采取行动。
通过识别这些方面，SDumont的管理人员可以将精力集中在改善系统性能和可用性上。他们可以评估采用I/O转发层或其他透明中间件解决方案，以合并小型操作并减轻高读取需求；修订默认的分片策略；实现自动负载均衡器以平衡存储服务器的不平衡；评估Lustre内部的元数据改进；评估实施自动调整I/O堆栈的框架；并与需求高的项目联系，以解决特殊要求。
在未来的工作中，我们计划改进应用程序的识别，尤其是在那些大型检测到的群组中。更好的识别还将有助于为面向特定应用程序的I/O优化框架提供附加信息。我们还计划改进分析工具的可扩展性和性能。本文中的所有数据、源代码和分析结果都可以在附带的存储库中找到（[9]）。
---【本文完】---
近期受欢迎的文章：
我们正处于数十年未见之大机遇中
新技术爆发式发展，催生新产品
然而，颠覆式创新并非简单的技术堆叠
而是异常复杂的系统工程
需要深度洞察
欢迎一起分享思考和见解