https://docs.aws.amazon.com/zh_cn/efs/latest/ug/performance.html#throughput-modes
下文概述 Amazon EFS 性能，讨论可用的性能和吞吐量模式，并提供一些有用的性能提示。
性能概述
Amazon EFS 文件系统分布在不受数量限制的存储服务器之间。这种分布式数据存储设计使文件系统能够弹性地增长到 PB 级，并实现从 Amazon EC2 实例到数据的大规模并行访问。Amazon EFS 的分布式设计避免了传统文件服务器固有的瓶颈和限制。
这种分布式数据存储设计意味着多线程应用程序和同时从多个 Amazon EC2 实例访问数据的应用程序会带来巨大的聚合吞吐量和 IOPS。大数据和分析工作负载、媒体处理工作流、内容管理和 web 服务等都属于这类应用程序。
此外，Amazon EFS 数据分布在多个可用区 (AZ) 中，从而可提供高度持久性和可用性。下表对 Amazon 文件和数据块云存储服务的高性能和存储特性进行了比较。
|
性能比较：Amazon EFS 和 Amazon EBS
| ||
|---|---|---|
| Amazon EFS | Amazon EBS 预置 IOPS | |
| 每次操作的延迟 | 低且一致的延迟。 | 最低且一致的延迟。 |
| 吞吐量规模 | 每秒 10+ GB。 | 每秒最多 2 GB。 |
|
存储特性比较：Amazon EFS 和 Amazon EBS
| ||
|---|---|---|
| Amazon EFS | Amazon EBS 预置 IOPS | |
| 可用性与持久性 | 数据冗余存储在多个可用区中。 | 数据冗余存储在一个可用区中。 |
| 访问 | 多个可用区的多达数千个 Amazon EC2 实例可以同时连接到一个文件系统。 | 一个可用区的一个 Amazon EC2 实例可以连接到一个文件系统。 |
| 使用案例 | 大数据和分析、媒体处理工作流、内容管理、Web 服务和主目录。 | 引导卷、事务型数据库和 NoSQL 数据库、数据仓库和 ETL。 |
Amazon EFS 的分布式特性实现了高水平的可用性、持久性和可扩展性。这种分布式架构使得每次文件操作只产生很小的延迟开销。由于这种每次操作的延迟，总吞吐量通常会随着平均 I/O 大小增加而增加，因为开销在大量数据之间分摊。Amazon EFS 支持高度并行化的工作负载（例如，从多个线程和多个 Amazon EC2 实例使用并行操作），从而实现巨大的聚合吞吐量和每秒操作数。
Amazon EFS 使用案例
Amazon EFS 旨在满足以下使用案例的性能需求。
大数据与分析
Amazon EFS 提供大数据应用程序所需的规模和性能，这些应用程序需要计算节点具有高吞吐量以及“写入后读取一致性”和低延迟文件操作。
媒体处理工作流
媒体工作流 (如视频编辑、演播室制作、广播处理、声音设计和渲染等) 通常依赖于共享存储来操作大型文件。具有高吞吐量和共享文件访问的强数据一致性模型可以缩短执行这些作业所需的时间，并将多个本地文件存储库整合到一个位置以供所有用户使用。
内容管理和 Web 服务
Amazon EFS 为内容管理系统提供持久的高吞吐量文件系统，这些内容管理系统为各种应用 (如网站、在线出版物和存档) 存储和提供信息。
主目录
Amazon EFS 可以为拥有众多需要访问和共享公共数据集的组织提供存储。管理员可以使用 Amazon EFS 创建一个可供整个组织的人员访问的文件系统，并在文件或目录级别为用户和组建立权限。
性能模式
为了支持各种云存储工作负载，Amazon EFS 提供了两种性能模式。您应在创建文件系统时选择其性能模式。
两种性能模式没有额外成本，因此，无论您选择哪种性能模式，您的 Amazon EFS 文件系统的计量和计费方式都是一样的。有关文件系统限制的信息，请参阅Amazon EFS 文件系统的限制。
创建 Amazon EFS 文件系统后，其性能模式将无法再更改。
通用性能模式
我们建议对于绝大多数 Amazon EFS 文件系统采用通用性能模式。通用性能模式非常适合对延迟敏感的使用案例，如 Web 服务环境、内容管理系统、主目录和一般文件服务。如果您在创建文件系统时未选择性能模式，Amazon EFS 默认选择通用模式。
最大 I/O 性能模式
最大 I/O 模式下的文件系统可以扩展到更高级别的聚合吞吐量和每秒操作数。此扩展完成，但以稍高的文件元数据操作延迟为代价。诸如大数据分析、媒体处理和基因组分析等高度并行化的应用程序和工作负载可以受益于这种模式。
使用合适的性能模式
具体应该使用哪种性能模式，我们的建议如下：
-
使用默认通用性能模式创建新文件系统。
-
运行您的应用程序 (或类似于您的应用程序的使用案例) 一段时间，测试它的性能。
-
在性能测试期间监视 Amazon EFS 的 PercentIOLimit Amazon CloudWatch 指标。有关访问该指标以及其他指标的更多信息，请参阅 Amazon CloudWatch 指标。
如果在测试期间的大部分时间返回的 PercentIOLimit 百分比达到或接近 100%，您的应用程序应使用最大 I/O 性能模式。否则，应使用默认的通用模式。
要移至其他性能模式，请将数据迁移到在其他性能模式下创建的其他文件系统。您可以使用 DataSync 在两个 EFS 文件系统之间传输文件。要了解更多信息，请参阅“将数据传输到 Amazon EFS”。
某些对延迟敏感的工作负载需要由最大 I/O 性能模式提供更高的 I/O 级别以及由通用性能模式提供的更低延迟。对于此类工作负载，我们建议创建多个通用性能模式文件系统。在这种情况下，我们建议将应用程序工作负载分散到所有这些文件系统间，只要工作负载和应用程序可以支持它即可。
通过采用这种方法，您可以创建一个逻辑文件系统，并在多个 EFS 文件系统间对数据分片。每个文件系统都挂载为一个子目录，并且您的应用程序可以并行访问这些子目录。这种方法允许对延迟敏感的工作负载扩展到每秒更高级别的文件系统操作，并跨多个文件系统进行聚合。同时，这些工作负载可以利用由通用性能模式文件系统提供的较低延迟。
吞吐量模式
有两种吞吐量模式可供您的文件系统选择：突增吞吐量和预置吞吐量。在突增吞吐量模式下，Amazon EFS 上的吞吐量将随着标准存储类别中文件系统大小的增大而增加。有关 EFS 存储类别的更多信息，请参阅 EFS 存储类别。使用预置吞吐量 模式，您可以即时预置与存储的数据量无关的文件系统的吞吐量 (MiB/s)。
只要自上次降低以来超过 24 小时，您就可以在预置吞吐量模式下降低文件系统吞吐量。此外，只要自上次吞吐量模式更改以来已超过 24 小时，您就可以在预置吞吐量模式和默认突增吞吐量模式之间进行更改。
随突增模式扩展的吞吐量
在突增吞吐量模式下，Amazon EFS 上的吞吐量将随着标准存储类别中存储的文件系统的增大而增加。基于文件的工作负载通常会猛增，短时间内吞吐量较高，其余时间吞吐量较低。因此，Amazon EFS 被设计为可在一段时间内突增到高吞吐量。
所有文件系统，不管其大小如何，都能突增到 100 MiB/s 的吞吐量。那些超过 1 TiB 的标准存储类别可以突增到每 TiB 文件系统存储数据 100 MiB/s。例如，一个 10 TiB 的文件系统可以突增到 1,000 MiB/s 吞吐量 (10 TiB x 100 MiB/s/TiB)。文件系统可能突增的时间部分由其大小决定。突增模型的设计使典型的文件系统工作负载几乎在任何需要的时候都可以突增。对于使用突增吞吐量模式的文件系统，允许的吞吐量仅基于 Standard 存储类别中存储的数据量确定。有关 EFS 存储类别的更多信息，请参阅 EFS 存储类别。
Amazon EFS 使用积分系统来判断文件系统何时可以突增。随着时间推移，每个文件系统都以一定基准速率（取决于存储在标准存储类别中的文件系统的大小）获得积分。文件系统在读取或写入数据时使用积分。基准速率为每 TiB 存储 50 MiB/s (相当于每 GiB 存储 50 KiB/s)。
累计的突增积分使文件系统可以推高吞吐量，使其高于其基准速率。文件系统可以以其基准速率持续推动吞吐量，每当文件系统不活动或吞吐量低于其基准速率时，它就会累计突增积分。
例如，如果 100 GiB 文件系统在 95% 的时间内处于不活动状态，则可以在 5% 的时间内突增（以 100 MiB/s 速率）。在一个 24 小时周期内，文件系统获得相当于 432000 MiB 的积分，可用于以 100 MiB/s 速率突增 72 分钟。
如果大于 1 TiB 的文件系统在 50% 的时间内处于不活动状态，则始终可以在其余 50% 的时间内突增。
下表提供了突增行为的示例。
| 文件系统大小 | 聚合读取/写入吞吐量 |
|---|---|
| 一个 100 GiB 文件系统可以... |
|
| 一个 1 TiB 文件系统可以... |
|
| 一个 10 TiB 文件系统可以... |
|
| 通常，一个更大的文件系统可以... |
|
计算基准速率所使用的最小文件系统大小为 1 GiB，因此，所有文件系统至少具有 50 KiB/s 基准速率。
确定基准速率和突增速率时所使用的文件系统大小与通过 DescribeFileSystems 操作得到的计量大小相同。
小于 1 TiB 的文件系统可以获得的积分可达到最高 2.1 TiB 积分余额，对于大于 1 TiB 的文件系统，可达到每 TiB 存储 2.1 TiB 的积分余额。这种方法意味着文件系统可以累积足够的积分来持续突增长达 12 小时。
下表提供了不同大小文件系统更详细的突增行为示例。
| 文件系统大小 (GiB) | 基准聚合吞吐量 (MiB/s) | 突增聚合吞吐量 (MiB/s) | 最大突增持续时间 (分钟/天) | 文件系统突增时间百分比 (每天) |
|---|---|---|---|---|
| 10 | 0.5 | 100 | 7.2 | 0.5% |
| 256 | 12.5 | 100 | 180 | 12.5% |
| 512 | 25.0 | 100 | 360 | 25.0% |
| 1024 | 50.0 | 100 | 720 | 50.0% |
| 1536 | 75.0 | 150 | 720 | 50.0% |
| 2048 | 100.0 | 200 | 720 | 50.0% |
| 3072 | 150.0 | 300 | 720 | 50.0% |
| 4096 | 200.0 | 400 | 720 | 50.0% |
如前所述，新文件系统最初具有 2.1 TB 突增积分余额。利用这一初始余额，您可以在不消耗从存储中获得的任何积分的情况下，以 100 MB/s 速率突增 6.12 小时。这个起始公式计算为 2.1 x 1024 x (1024/100/3600)，得到 6.116 小时，四舍五入为 6.12。
管理突增积分
当文件系统具有正突增积分余额时，就可以突增。您可以通过查看 Amazon EFS 的 BurstCreditBalance Amazon CloudWatch 指标了解文件系统的突增积分余额。有关访问该指标以及其他指标的更多信息，请参阅监控 Amazon EFS。
文件系统的突增能力 (时间长短和突增速率) 与其大小直接相关。越大的文件系统越能够以更大的速率突增越长的时间。在某些情况下，应用程序可能需要更多突增（即，您可能会发现您的文件系统已耗尽了突增积分）。在这些情况下，您应增加文件系统大小，或者切换到预置吞吐量模式。
使用您的历史吞吐量模式来计算维持您需要的活动水平所需的文件系统大小。下面概括了具体步骤。
计算维持您需要的活动水平所需的文件系统大小
-
通过查看您的历史使用情况确定您的吞吐量需求。从 Amazon CloudWatch 控制台中，将
TotalIOBytes指标的sum统计与过去 14 天里每天的聚合进行核对。找出具有最大TotalIOBytes值的那一天。 -
将该值除以 24 小时、60 分钟、60 秒和 1024 字节，得到您的应用程序在那一天所需的平均 KiB/s 值。
-
通过将平均吞吐量值 (KiB/s) 除以 EFS 提供的基准吞吐量值 (50 KiB/s/GiB) ，来计算维持此平均吞吐量所需的文件系统大小(GiB)。
通过预置模式指定吞吐量
预置吞吐量模式适用于具有高吞吐量到存储 (MiB/s/TiB) 比率的应用程序，或具有比突增吞吐量模式允许的比率大的要求的应用程序。例如，假设您正在将 Amazon EFS 用于发工具、Web 服务或内容管理应用程序，而文件系统中的数据量相对于吞吐量需求来说是较低的。您的文件系统现在可以获得应用程序所需的高吞吐量，而无需填充文件系统。
使用预置吞吐量模式会产生额外费用。使用预置吞吐量模式，您需要为所使用的存储以及基于所提供内容预置的吞吐量付费。您所提供的吞吐量取决于 Standard 存储类中存储的数据量。有关 EFS 存储类别的更多信息，请参阅 EFS 存储类别。有关定价的更多信息，请参阅 Amazon EFS 定价。
无论您选择何种吞吐量模式，吞吐量限制都保持不变。有关这些限制的更多信息，请参阅您可以提高的 Amazon EFS 配额。
如果文件系统处于预置吞吐量模式，您可以根据需要随时增加文件系统的预置吞吐量。只要自上次降低以来超过 24 小时，您就可以在预置吞吐量模式下降低文件系统吞吐量。此外，只要自上次吞吐量模式更改以来已超过 24 小时，您就可以在预配置吞吐量模式和默认突增吞吐量模式之间进行更改。
如果文件系统的计量大小提供的基准速率高于您预置的吞吐量，则文件系统将遵循默认 Amazon EFS 突增吞吐量模型。在突增吞吐量模式下，您不会在文件系统的权限下被收取预置吞吐量费用。有关更多信息，请参阅 随突增模式扩展的吞吐量。
使用合适的吞吐量模式
默认情况下，我们建议您以突增吞吐量模式运行应用程序。如果遇到性能问题，请检查 BurstCreditBalance CloudWatch 指标。如果 BurstCreditBalance 指标的值为零或稳步下降，则预置吞吐量适合于您的应用程序。
在某些情况下，您的文件系统可能在预置吞吐量模式下运行而没有性能问题。但与此同时，您的 BurstCreditBalance 在长时间的正常运行中会持续增长。在这种情况下，请考虑减少预置吞吐量来降低成本。
如果您计划将大量数据迁移到您的文件系统，请考虑切换到预置的吞吐量模式。在这种情况下，您可以预置超出您的已分配突增容量的更高吞吐量，以加快加载数据。迁移之后，请考虑降低预置的吞吐量，或切换到突增吞吐量模式以进行正常操作。
将驱动文件系统所达到的平均吞吐量与 PermittedThroughput 指标进行比较。如果驱动文件系统所达到的计算出的平均吞吐量小于允许值，请考虑更改吞吐量以降低成本。
在某些情况下，您在正常操作期间计算出的平均吞吐量可能等于或低于突增吞吐量模式下基准吞吐量与存储容量之比。该比率为每 TiB 存储数据 50 MiB/s。在这种情况下，请考虑改用突增吞吐量模式。在其他情况下，在正常操作过程中计算出的平均吞吐量可能高于此比率。在这些情况下，请考虑将预置吞吐量降低到当前预置吞吐量与正常操作期间计算出的平均吞吐量之间的某个点。
您可以使用 AWS 管理控制台、AWS CLI 或 EFS API 更改文件系统的吞吐量模式。通过 CLI，请使用 update-file-system 操作。通过 EFS API，请使用 UpdateFileSystem 操作。
如前所述，新文件系统最初具有 2.1 TB 突增积分余额。利用这一初始余额，您可以在不消耗从存储中获得的任何积分的情况下，以 100 MB/s 速率突增 6.12 小时。这个起始公式计算为 2.1 x 1024 x (1024/100/3600)，得到 6.116 小时，四舍五入为 6.12。