在王坚博士的《在线》一书中提到，单纯谈数据的“大”，意义是不大的。欧洲核子研究中心（CERN）进行一次原子对撞产生的数据大到惊人，而如何通过计算的形式去挖掘出这些数据背地的价值，才是数据意义的自身。HPC高性能计算，就是实现这种价值转换的重要伎俩。近年来，HPC的利用范畴曾经从纯学术扩大到资源勘探、气象预测、流体力学剖析、计算机辅助设计等更多场景。这些HPC应用程序会产生或依赖大量数据，并将其存储在PB级别的共享的高性能文件系统中。然而，无论是HPC利用的用户，还是高性能文件系统的开发人员，对这些文件的拜访模式理解都十分无限。
咱们在Fast20中发现了一篇很乏味的论文《Uncovering Access, Reuse, and Sharing Characteristics of I/O-Intensive Files on Large-Scale Production HPC Systems》，这篇论文钻研了超级计算机的生产环境上I/O密集型HPC利用对文件拜访模式。
据论文作者所知，这是第一篇对HPC零碎中IO密集型文件的拜访、重复使用以及共享个性进行深入研究的论文。这篇论文第一次揭示了（1）HPC中的各个文件是读密集型，还是写密集型，或是读写密集型；（2）在多个工作中，重复拜访同一个文件的工夫距离；（3）多个应用程序对同一个文件的共享行为。更进一步地，这篇论文还基于文件的IO时序，剖析了导致文件系统性能低下的次要起因，这些起因导致了在单次工作和屡次工作间的IO的性能稳定。
论文总结了十个发现，咱们联合本人的了解，补充了很多背景常识，摘要了其中的要点，和大家做个分享（后方及其高能），大家能够细细品读论文作者的钻研思路和伎俩，也能够间接浏览论文演绎的十大发现。以下文章中未注明的图表，均来自论文原文（图表标号应用原文中的标号）。感兴趣的同学能够浏览论文原文，也欢送大家和咱们一起探讨。
01 概述
在大规模高性能计算HPC集群上，各个利用的数据读写通常都在几十上百TB。过往对于IO特色上的钻研大多基于单个应用程序级别，针对特定利用提供底层存储的优化倡议。而大家对于HPC零碎中不同应用程序对各种文件的IO特点，理解十分无限。因为这须要在HPC生产环境中，跟踪利用在大量工作执行过程中产生的IO信息，家喻户晓，这种细粒度的跟踪和剖析，对系统的性能是会造成很大影响的，这也正是很难在HPC的生产环境中进行相似钻研的起因。然而，这种钻研还是极具价值的，它对于咱们存储研发人员更深刻了解针对文件的IO、文件重复读写的模式、IO性能上的稳定、优化文件搁置策略，都十分有意义。
论文的钻研应用的是轻量级的IO监控工具Darshan（Darshan旨在以最小的开销捕捉应用程序IO行为的精确状况，包含文件的拜访模式等特色。Darshan名称取自梵语单词“ sight”或“ vision”， https://www.mcs.anl.gov/research/projects/darshan/），论文作者团队在Top500超级计算机集群Cori的生产环境上，进行了长达四个月（累计近3600万个节点小时）的跟踪和剖析。
02 钻研的背景和分析方法
首先介绍一下Cori，超级计算机集群Cori在最新的世界HPC Top500中排名第十三位（https://www.top500.org/list/2019/11/），Cori具备约27 Pflop / s的峰值计算性能，蕴含9,688个Intel Xeon Phi和2388个Intel Haswell处理器。Cori应用的是基于磁盘的Lustre文件系统，该文件系统由约10,000块磁盘组成，这些磁盘被组织为248个Lustre OST。每个OST都配置有GridRAID，并具备用于解决IO申请的相应的OSS。文件系统的总大小约为30 PB，IO峰值带宽为744 GB / s。Cori是长这样的：
图片来自互联网
IO数据监控和采集。论文作者应用Darshan这个监控工具对应用程序进行文件IO拜访模式等特色的收集。在钻研期间，Cori上所有用户都默认启用了Darshan V3.10。Darshan收集了包含用户ID、作业ID、应用程序ID、开始工夫戳、完结工夫戳和过程数等要害信息。Darshan还针对代表性的IO接口类型 POSIX IO、MPI IO（Message Passing Interface，MPI是一种用于对并行计算机进行编程的通信协议，是一个用于进行消息传递的应用程序程序接口、协定和语义标准，MPI是当今高性能计算中被宽泛应用的IO编程模型，这种编程模型须要底层存储的反对）、STD（Standard）IO的IO调用接口进行了监控和统计。统计的指标包含读/写数据量、读/写/元操作的总工夫、执行IO的过程ID，以及不同应用程序过程中IO大小和IO工夫的稳定。最初，Darshan还收集了Lustre文件系统级别的一些指标，例如条带宽度和对文件条带化所波及的OST ID。然而，Darshan没有记录各个文件的理论大小，而只记录了文件被传输的数据的大小。在论文钻研期间，作者团队供收集了大概8400万条日志（每次工作执行对应一条日志），这些日志涵盖在8489个应用程序的5200万个日志文件中，波及651个用户和12.8 PB的数据传输（其中6.9 PB读取数据，5.9 PB写入数据）。
在以下篇幅中，会应用到几种图表，包含：
- 热度分布图，用于显示两个指标之间特定关系的关联水平。热度分布图色彩的强度示意显示两个坐标指标上对应的文件数。
- CMF图。CMF图用于显示横轴指标的累积散布。垂直的蓝色虚线用于批示横轴指标的平均值。一些CMF图显示的是一个指标的CoV（变异稳定系数（％），https://en.wikipedia.org/wiki/Coefficient_of_variation）的累计散布（简略来说，就是这个指标在多大范畴内稳定的累计概率状况），以突出显示这个指标的归一化稳定个性。
- Violin Plot，这些图用于以垂直格局显示指标不同值的密度（以文件数示意），程度的蓝色实线用于批示密度散布的平均值。
如何抉择IO密集型文件
后面提到过，Cori的Darshan日志蕴含了约5200万个文件。然而，分析表明，在钻研期间，大多数日志文件中执行的IO操作很少。图2横坐标示意计算工作中一个文件的传输数据量（读或写），纵坐标示意一个文件在多少个工作中被读写，不同色块代表波及的文件数量。从图中能够看出，大多数文件的IO小于100 GB，并且整个计算过程中只被拜访一次。实际上，超过99％的文件传输数据少于1 GB。这并不意味着理论文件大小小于1 GB，只是文件的数据传输量小于1 GB。
Figure 2: 超过99%（约等于5200万个）的文件传输数量<1GB，且钻研期间只被拜访一次
因而，大多数的文件对建设与HPC应用程序的次要IO模型无关的特色没有帮忙。这些文件包含用户正文、脚本、可执行文件、非IO密集型应用程序输入以及谬误日志等。而论文的钻研重点是 “IO密集型”文件，这些文件在钻研期间至多实现了100 GB的数据传输，并且至多被2次工作拜访，作者通过钻研这些IO密集型文件以捕捉最次要和最具代表性的IO模式。从这里开始，将这些IO密集型文件简称为“文件”。这些IO密集型文件的日志逾越了约40万次工作、791个应用程序、149个用户、8500个文件和7.8 PB的数据传输（4.7 PB的读取数据和3.1 PB的写入数据），超过70％的用户对2个以上的文件执行IO操作，每个用户均匀对57个文件执行IO。
文件分类
接下来，作者依据IO密集型文件执行的IO操作类型对这些文件进行分类，这有助于了解后续章节中针对不同类型文件拜访特点所失去的发现。图3（a）显示了每个文件读取数据传输量与写入数据传输量的热力求。文件能够分为三个不同的品种，右下方的一组由22％的文件组成，这些文件在四个月内传输的大部分为读取数据，论文将这些文件称为读密集型文件或RH（Read-Heavy）文件。左上方的一组由仅传输写数据的文件（写密集型文件或WH（Write-Heavy）文件）组成，占IO密集型文件的7％。位于文件右上角的一组具备最大的占比（占71％），由读写密集型文件组成（称为RW（Read-Write）文件）。
Figure 3: (a) IO密集型文件分为三组-读密集型/写密集型/读写密集型
发现1. HPC文件可分为读密集型（RH）、写密集型（WH）或读写密集型（RW） 。论文首次量化了文件中有很大一部分是读密集型的文件（占22％），小局部是写密集型文件（占7％），这7％的文件被一直写入，但未被读取。有71％的HPC文件是RW文件（即读写密集型文件）。这种的文件分类可用于设置文件搁置决策，包含Burst Buffer区在内的分层存储搁置策略，其中每个层别离实用于不同类型的IO操作。
读写工作分类
只管能够将文件依据IO类型分为三种，但它们能够被多个“应用程序的工作”拜访，各工作都能够执行读取和写入操作。工作是指在计算节点上运行的各种作业，由一个节点内的多个MPI过程以及可能的共享内存的线程组成。作者发现，绝大多数工作要么执行读密集型操作，要么执行写密集型。为了证实这一点，作者应用以下公式计算每次工作的读写数据量之差：|数据读取-写入数据| /（数据读取+写入数据）。该公式的值范畴是0到1，1示意工作所解决的所有数据都是只读或只写，0示意读取和写入数据传输量相等。图3（b）显示所有工作中，超过82％的值十分靠近1，即它们是读密集型或写密集型的。在IO上下文中，作者将读密集型工作简称为“读工作”，将写密集型工作称为“写工作”。作者发现其中69％是读密集型工作，而31％是写密集型工作。RH文件次要由读密集型工作读取，WH文件次要由写密集型工作写入，这两类工作都会对RW文件进行操作。对工作的分类有助于在后续章节中建设工作之间的生产者-消费者关系模型。
Figure 3: (b) >82% 的工作只执行读或写操作
发现2.令人诧异的是，古代HPC应用程序在单次工作中次要偏向于仅执行一种类型的IO：要么读，要么写。这与普遍认为HPC应用程序在一个工作期间，同时具备读取和写入IO阶段的假如相同。这一发现表明，更迷信的工作流逐渐取代了传统的单体化应用程序（将不同工作会集到一个工作中）的设计。非单体化应用程序的存在，为更好地调度大型工作流的不同组件提供了机会，从而防止了不同工作流之间的IO争用。
03 后果探讨和剖析
接下来，论文剖析了多任务反复拜访数据及多利用共享数据的特点，并钻研了负载是否平衡，以及工作内和不同工作间IO稳定的特色。
文件复用的特点
在之前，作者将工作分为了读工作或写工作，并且发现读工作的总数约为写工作数量的2倍。接下来，为了理解复用同一文件所破费的均匀工夫（工作达到工夫定义如图4所示），作者定义了不同工作的达到工夫的概念。
Figure 4: 同一个文件读工作或写工作距离的定义
图5（a）显示，同一个文件经验的不同读工作的均匀达到工夫距离为47小时，而写工作的均匀达到工夫距离为55小时。然而，均匀而言，80％的文件只有在50-55小时后才会再次被读取和写入。作者留神到，均匀达到间隔时间比Cori上作业的均匀运行工夫长得多（这些零碎上> 80％的HPC作业在不到2小时内实现）。
Figure 5(a): 大多数状况下对同一个文件的再次拜访间隔时间在50-55小时
发现3.对于80％的文件，读写工作具备类似的达到工夫距离，都超过2天。论文首次发现，大多数文件从新拜访工夫距离（>50小时）比作业的运行工夫更长。这意味着HPC零碎有工夫对一些心愿在一段时间内不沉闷的数据进行压缩，或者将一些接下来行将拜访到的数据通过预读和缓存的形式加载到Burst Buffer层中。
具备类似达到间隔时间的读写工作促使调研团队测试读写工作是否会背靠背执行，如果是这样，这种的执行秩序会继续多长时间。论文计算了每个文件的间断读和写工作的均匀次数（如图4所示），并将散布状况绘制在图5（b）中。
Figure 5(b): 均匀间断读工作数为13，均匀间断写工作数为3
超过80％的文件经验过2次或更屡次间断读工作，而超过65％的文件经验2次或更屡次间断写工作。大多数文件经验2次连续读运行（65％）和2次连续写运行（50％）。这表明文件是在屡次读工作和屡次写工作的交替中进行拜访的，这与后面察看到RW文件占总体的比例（71％）是统一的。然而，许多文件会经验大量间断读工作（因为RH文件）。事实上，一个文件经验的均匀间断读工作的次数超过14，而均匀间断写工作的次数<4。读工作的次数仅为写工作次数的2.2倍（读写工作分类大节中提到），然而均匀间断读工作次数为间断写工作次数的4.3倍。这表明对于大多数RW文件而言，数据仅生产了几次，而后被耗费了很屡次。该察看结果表明，迷信模拟计算通常会在某些工作期间生成数据，而后在随后的几次工作中将其用作驱动后续程序的输出，以摸索不同的潜在门路或剖析模仿景象。作者留神到，间断的写工作并不意味着所有先前写入的数据都被重写或抛弃。一些迷信工作流可能会在两个间断的写工作中追加数据，而后在后续工作中读取该文件的一部分用作剖析。
发现4. HPC文件均匀经验几次间断的写工作和一长串的间断读工作。这个发现能够帮忙利用MPI“hints”API来领导零碎行将要执行的IO类型，以及对IO服务器进行分区，以别离提供RH文件（执行屡次间断读）和RW文件（用于读取和写入工作），缩小IO竞争，从而进步IO性能。
多应用程序间的文件共享特色。接下来的工作，为了将生产者与消费者的关系更进一步，从而理解生产者和消费者是雷同的应用程序还是不同的应用程序。作者留神到所有拜访同一个文件的应用程序均由同一用户运行。因而，对于任何文件，生产者和使用者应用程序都属于同一用户。此外，因为权限问题，默认状况下，也不会将文件在多个用户之间共享。图6（a）显示了拜访文件的应用程序数量的CMF，超过67％的文件被至多2个应用程序拜访独特拜访，表明文件常常被多个应用程序共享。
Figure 6(a): 超过65%的文件被至多两个应用程序共享拜访
图6（b）展现出了对文件执行IO的每个利用的达到间隔时间的CMF。每个应用程序的均匀达到间隔时间为31小时，比单个读工作的均匀达到间隔时间（> 50小时）要低得多。因而，对于大多数文件，有两个或多个应用程序充当生产者和使用者，而不只是被单个应用程序拜访。这与作者的发现是统一的：被多个应用程序拜访的大多数文件（86％）是RW文件（这些共享文件中只有12％是RH文件，只有2％是WH文件）。
Figure 6(b): 不同应用程序对同一个文件执行IO操作的均匀达到工夫距离为31小时
发现 5. HPC文件由多个应用程序共享，并且每个应用程序都会执行读取和写入操作，同时充当生产者和使用者。这些工作的达到间隔时间还表明，生产者和消费者在工夫上显着离开，从而限度了跨应用程序拜访时应用缓存的有效性。
IO数据拜访特点
在文件复用特点中，作者钻研了如何在屡次工作中应用雷同的文件。接下来，论文将剖析在屡次工作中数据拜访特色会产生什么样的变动。图6（c）显示了每次通过读工作和写工作传输的数据量的CMF。能够察看到，均匀而言，每次读工作传输17 GB的数据，而每次写工作传输25 GB的数据，50％的读工作传输数据量少于1 GB。
Figure 6(c) 均匀每个读/写工作传输的数据量别离为17GB和25GB
发现6. 尽管读工作比写工作要多，且读工作传输的数据总量大于写工作，然而令人诧异的是，单次写工作所传输的数据量要单次读工作要多。均匀而言，每次写工作运行的IO次数是读工作的1.4倍。能够利用此发现来限度同时执行的写工作数量，从而在零碎级别更好地治理IO争用问题。回忆一下先前的发现，HPC利用在一次工作中会次要偏向于只执行一种类型的IO，因而，“写工作”能够轻松地被检测和分类，从而限度并发写入的数量。
既然曾经发现不同的工作会传输不同数量的数据，接下来要钻研的问题是这种差别会如何影响后端OST。图7显示了在钻研期间每个OST传输的标准化IO数据。
Figure 7: 每个OST传输的数据量存在很大差别，只管文件数量、利用数量和用户数量总体是平衡的，均匀每个读/写工作传输的数据量别离为17GB和25GB
有意思的是，每个OST传输多少数据有很大的不同。最不沉闷的OST仅是最沉闷OST的13％。另一方面，当查看每个OST上的文件数，应用这些文件的应用程序数以及生成文件的用户数时，作者发现散布范畴要窄得多。
发现7. 对于在论文中钻研的基于Lustre的零碎，OST具备容量均衡的性能，以确保在文件创建时的利用率大抵相等，但这并不能保障动静负载平衡。因而，在每个OST随时间推移察看到的负载（数据传输）方面存在很大的不平衡，这也体现出动静文件迁徙（以后在Lustre文件系统中并不反对），对只读文件的正本及缓存（能让IO负载失去摊派）的重要性。
接下来，作者钻研变动的OST争用将如何影响各个并发运行的过程的IO工夫，这些过程可能并行拜访不同的OST。在此剖析中，作者别离剖析了Cori应用的三种不同的IO接口：POSIX 、MPI、和STD IO。首先，看一下应用每个接口传输的数据量。图8（a）显示POSIX是最罕用的I / O接口，均匀每次工作每个文件传输大概260 GB数据，MPI接口均匀每次工作每个文件将传输约190 GB的数据。正如并行HPC应用程序所冀望的那样，STD是最不罕用的接口。
Figure 8(a): POSIX和MPI接口承当了绝大多数数据的传输工作
图8（b）显示了每次工作的单个过程上每个文件执行IO传输数据量的标准差（标准差用于形容不同过程间数据传输的偏差）。均匀而言，所有三个接口的标准差都十分小。例如，过程内POSIX IO执行的数据量传输的均匀标准偏差小于1.5 GB，与应用POSIX传输的均匀数据量（260 GB）相比能够忽略不计。
Figure 8(b): 在同一个应用程序内，不同过程间IO数据量偏差很小
另一方面，图8（c）显示了每次工作中单个过程内每个文件执行IO工夫的标准差（用于形容不同过程执行IO工夫的稳定状况）。对于应用POSIX接口执行的IO，此标准差特地高。这是因为通常在应用POSIX接口时，每个过程对不同的文件执行IO，而在应用MPI IO接口时，所有过程对同一个共享文件执行IO。因为Cori超级计算机上的默认条带宽度为1，所以超过99％的文件仅在1个OST上进行条带化。因而，如果应用程序对多个文件并行执行IO，因为文件可能映射到不同的OST上，则这些利用很有可能对多个OST并行执行IO。因而，当应用POSIX IO时，这些OST上不同的资源争用级别会极大地影响各个过程的IO工夫。
Figure 8(c): 各个过程在IO工夫上的偏差很大
发现8. OST负载不均衡会导致同时执行IO的过程所耗费的IO工夫稳定较大，尤其是当过程对不同的OST执行IO时（例如POSIX IO）。这导致较快的过程必须期待较慢的过程实现，能力实现IO，而后能力持续进行计算，从而节约了HPC零碎上贵重的计算周期。
IO负载在不同工夫上的稳定。以前，钻研人员们曾经发现OST IO不均衡和争用会导致单个工作的IO工夫产生稳定。下一步，论文摸索的是IO负载在不同工夫上的个性。图9（a）显示了一天中不同工夫端传输的数据总量。能够察看到，最密集的IO是由本地工夫凌晨3点到凌晨5点之间开始的工作触发的。
Figure 9(a): 凌晨3点到5点是数据IO的高峰期
值得注意的是，Cori的用户遍布寰球，因而特定的本地工夫（即凌晨）不能批示本地用户何时最沉闷，上面的剖析不肯定在不同因素之间建设间接的因果关系，而是尝试解释察看到的趋势。在图9（b）中，展现了各个工作在一天中不同时段的IO耗时趋势。纵轴是各个工作在指定时间段，针对同一个文件执行IO所破费的工夫与IO最长工夫的比值（归一化），从而不便在各个文件之间进行标准化比拟。因为凌晨3点到5点这段时间IO最为沉闷，作者察看到从凌晨3点到5点，以及凌晨5点之后的几个小时，工作的IO耗时最长。只管这个IO峰值时间段传输的数据最多，但相对来说，这段时间内工作的IO所破费的工夫稳定还是比拟小的。
Figure 9(b): 凌晨3点到5点以及之后的几个小时，对同一个文件IO破费的工夫最多
有意思的是，如图9（c）显示，只管IO耗时的稳定在全天所有时段内都十分高（> 20％），但在峰值IO期内开始的工作而言，IO耗时的稳定反而最低。CoV（稳定系数）是针对同一时刻开始的对同一文件的工作进行计算的。IO稳定CoV趋势（图9（c））与IO耗时趋势图简直相同（图9（b）） 。实际上，IO耗时和IO的CoV的相干指数为-0.94，这表明两者之间存在强烈的负相关性，也就是说，当IO流动最频繁的时候，用户能够预期的IO耗时变动反而会略低，即，如果用户A每天在忙碌的IO流动期间开始雷同的工作，与在IO流动不那么频繁的时间段启动雷同工作的用户B相比，用户A的工作IO耗时稳定更小。当然，要衡量的是用户A所破费的均匀IO耗时要比用户B长。这是因为当IO流动频繁时，OST竞争强烈，这可能会减慢所有IO，因而，IO耗时变动较小。然而，OST处于非竞争状态，并且IO更快时，IO耗时的稳定趋势就更加显著。
Figure 9(c): 不同工作的IO耗时CoV在最忙碌的时间段反而最小
发现9.不同时段的IO负载不均衡会导致同一工作的IO耗时在一天中的不同时段有所不同。而且，IO耗时的稳定偏差在一天中的时段散布与IO耗时呈强烈的负相关性。这表明，HPC零碎须要应用新的技术来升高各个工作中的IO耗时偏差（即同一应用程序的过程实现IO消耗工夫偏差较大），因为目前IO耗时的偏差在全天所有时段内依然较大（> 20％）。
不同工作的IO稳定。接下来要解决的下一个问题是，如果存储系统负载存在工夫散布上的不均衡，是否会导致IO耗时在不同工作上发生变化？在发现9中揭示的是同一时段内开始的工作中的IO稳定。当初须要看看不管开始时间段如何，拜访同一文件的不同工作的IO稳定。首先，作者探讨针对同一文件，不同工作的数据传输量偏差。图10（a）显示了对于一个文件，不同工作传输数据量CoV的CMF。总体而言，超过80％的文件的CoV小于5％，这表明从不同工作的IO传输数据量的变动稳定微不足道。RH文件如此，RW文件更是如此，同一个RW文件在绝大多数状况下，都会被工作产生和耗费类似数量的数据。同一个WH文件在不同工作中传输数据量的稳定最大，均匀CoV为35％。
图10（b）显示了每个文件在不同工作中的IO耗时的CoV。针对所有文件，即便不同工作间传输的数据量没有显着变动（下面的论断），但传输此数据所破费的工夫却存在很大的差别：两次工作之间的IO耗时的均匀CoV为39％。RH文件在不同工作的IO工夫偏差最大，均匀CoV为68％，即便它们传输的数据量变动最小。这是因为以下事实造成的：因为工夫负载不均衡，OST在不同时间段竞争水平不同，因为读工作均匀传输的数据量少于写工作（发现6中探讨的那样），因而这种负载不均衡的影响在其工作的IO耗时上尤为突出，进而对RH的影响最大。
Figure 10: 针对同一文件，不同工作对只读文件传输数据量的偏最小（均匀CoV 12%），但IO耗时偏差最大（均匀CoV39%）
发现10. HPC文件往往在不同工作中传输的数据量类似，然而就传输数据所破费的工夫而言，它们确实存在很大差别。对于RH文件而言，IO数据量的稳定最小，但IO耗时稳定最大，这意味着大家须要对RH文件的IO耗时稳定偏差投入更多关注和改善。
04 后记
Cori特定环境和工作负载的影响。正如预期的那样，论文的各个发现受到在美国国家能源钻研迷信计算中心（NERSC）和Cori在NERSC零碎环境中执行的HPC负载的影响，依然具备肯定的局限性。因而，论文的发现不能照原样推广到所有HPC零碎中，然而论文所形容的工作提供了一种方法论，能够在其余HPC核心进行相似性质的钻研，从而优化HPC中的存储系统。
咱们认为，这篇论文的最大意义，并不在于其揭示了Cori中HPC负载的IO特点，而在于其形容了一种事实可行的考察IO模型及IO稳定等个性的方法论。任何大型的HPC零碎，都不是欲速不达的，任何调优也不能是无根之水，只有基于迷信的调研和剖析，能力做出最正当的优化和配置。