共计 10006 个字符，预计需要花费 26 分钟才能阅读完成。
在王坚博士的《在线》一书中提到，单纯谈数据的“大”，意义是不大的。欧洲核子研究中心（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 零碎，都不是欲速不达的，任何调优也不能是无根之水，只有基于迷信的调研和剖析，能力做出最正当的优化和配置。
