为什么我的 EFS 文件系统性能较慢？

简短描述

Amazon EFS 的分布式多可用区架构会为每个文件操作带来较小的延迟开销。由于延迟开销会分摊到更多的数据上，因此总吞吐量通常会随着平均 I/O 大小的增加而提高。

Amazon EFS 的性能取决于多种因素，包括以下因素：

• EFS 的存储类。
• 性能和吞吐量模式。
• 在 EFS 上执行的操作类型（例如元数据密集型等）。
• EFS 中存储的数据的属性（如文件大小和数量）。
• 装载选项。
• 客户端限制。

解决方法

EFS 的存储类

有关更多信息，请参阅性能摘要。

性能和吞吐量模式

性能模式

Amazon EFS 提供两种性能模式：通用型和最大输入/输出。应用程序可以弹性地将其 IOPS 扩展到与性能模式相关的限制。要确定要使用的性能模式，请参阅 Amazon EFS 中的通用和最大 I/O 性能模式之间有何区别？

吞吐量模式

基于文件的工作负载通常会猛增，短时间内吞吐量较高，而在很长一段时间内吞吐量较低。Amazon EFS 被设计为可在一段时间内突增到高吞吐量。

配置的吞吐量和 IOPS 会影响 Amazon EFS 的性能。最佳做法是对工作负载要求进行基准测试，以帮助您选择适当的吞吐量和性能模式。选择预配置吞吐量时，请选择适合您的工作负载要求的值。在突增吞吐量模式下，您可以使用虚拟文件增加 Amazon EFS 的大小以增加基准吞吐量。要分析文件系统消耗的吞吐量和 IOPS，请参阅在 Amazon EFS 中使用指标数学。

Amazon EFS 还可以扩展到数 PB 的存储容量，并具有两种吞吐量模式：突增和预配置。在突增模式下，EFS 文件系统的大小越大，吞吐量扩展越大。对于预配置模式，文件系统的吞吐量以 MB/s 为单位进行设置，与数据量无关。有关吞吐量模式的更多信息，请参阅 Amazon EFS 突增积分的工作原理是什么？

在 EC2 实例上执行的操作类型

元数据 I/O 操作

在以下情况下，EFS 性能会受到影响：

• 当文件大小较小时，因为它是分布式系统。这种分布式架构使得每次文件操作的延迟开销都较低。由于每次操作的延迟都较低并且延迟开销会分摊到更多的数据上，因此总吞吐量通常会随着平均 I/O 大小的增加而提高。
• 如果工作负载或操作连续生成许多小文件，则共享文件系统的性能会受到影响。这会导致每次操作的开销增加。
• 如果您的应用程序执行元数据密集型操作，例如“ls”、“rm”、“mkdir”、“rmdir”、“lookup”、“getattr”或“setatt” 等，则会发生元数据 I/O。任何要求系统提取特定块地址的操作都被视为元数据密集型工作负载。有关更多信息，请参阅以下内容：
  计量：Amazon EFS 如何报告文件系统和对象大小。
  优化小文件性能。

装载选项

• 如果您使用 amazon-efs-utils 装载文件系统，则默认情况下会应用推荐的装载选项。
• 使用非默认装载选项可能会降低性能。例如，使用较小的 rsize 和 wsize、降低或关闭属性缓存。您可以查看 mount 命令的输出以查看当前使用的装载选项：

有关更多信息，请参阅在 EC2 实例上装载文件系统并进行测试。

示例命令

>> mount

示例输出

fs-EXAMPLE3f75f.efs.us-east-1.amazonaws.com:/ on /home/ec2-user/efs type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=<EXAMPLEIP>,local_lock=none,addr=<EXAMPLEIP>)

NFS 客户端版本

与 NFSv4.0（每秒少于 1,000 个文件）相比，网络文件系统 (NFS) 版本 4.1 (NFSv4) 协议为并行小文件读取操作（每秒大于 10,000 个文件）提供了更好的性能。

有关更多信息，请参阅 NFS 客户端装载设置。

客户端限制

EC2 实例的瓶颈

如果使用文件系统的应用程序没有提高 EFS 的预期性能，请优化应用程序。此外，对托管应用程序的主机或服务（例如 Amazon EC2、AWS Lambda 等）进行基准测试。EC2 实例上的资源紧缩可能会影响应用程序有效使用 EFS 的能力。

要检查 EC2 的配置是否不足以满足您的应用程序要求，请监控 Amazon EC2 CloudWatch 指标，例如 CPU、Amazon Elastic Block Store (Amazon EBS) 等。通过分析应用程序架构和资源需求的各种指标，可以帮助您确定是否应根据自己的需求重新配置应用程序或实例。

使用 4.0+ Linux 内核版本

为了获得最佳性能并避免各种已知的 NFS 客户端错误，最好使用具有 Linux 内核版本 4.0 或更高版本的 AMI。

这条规则的例外情况是 RHEL 和 CentOS 7.3 及更高版本。这些操作系统的内核收到了应用于 NFS v4.1 的修复和增强功能的向后移植版本。有关更多信息，请参阅 NFS 支持。

复制文件

使用 cp 命令复制文件时，您可能会遇到速度缓慢的情况。这是因为 copy 命令是一项串行操作，这意味着它一次复制一个文件。如果每个文件的文件大小都很小，则发送该文件的吞吐量很小。

在发送文件时，您可能还会注意到延迟。EFS 的分布式特性意味着它必须复制到所有挂载点，因此每次文件操作都会产生开销。因此，发送文件的延迟是预期的行为。

建议

最佳做法是运行并行 I/O 操作，例如使用 rsync。如果您使用的是 rsync，请注意 cp 和 rsync 在串行（单线程）操作中工作，而不是并行操作。这会使复制速度变慢。使用诸如 fpart 或 NU Parallel 之类的工具。Fpart 是一个工具，可帮助您对文件树进行排序并将其打包为“分区”。Fpart 附带一个名为 fpsync 的 shell 脚本，该脚本包装 fpart 和 rsync 以并行启动多个 rsync。Fpsync 提供了自己的嵌入式计划程序。通过这样做，您可以比使用更常见的串行方法更快地完成这些任务。

有关更多信息，请参阅 Amazon EFS 性能提示。

---

相关信息

NFS 客户端的配额