本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # Amazon EFS 性能规范 以下章节概述了 Amazon EFS 性能，还介绍了文件系统配置如何影响关键性能维度。我们还提供了一些用于优化文件系统性能的重要提示和建议。 **Topics** + [ ## 性能摘要 ](#performance-overview) + [ ## 存储类 ](#storage-perf) + [ ## 性能模式 ](#performancemodes) + [ ## 吞吐量模式 ](#throughput-modes) + [ # Amazon EFS 性能提示 ](performance-tips.md) + [ # Amazon EFS 性能问题排查 ](troubleshooting-efs-general.md) + [ # 排查 AMI 和内核问题 ](troubleshooting-efs-ami-kernel.md) ## 性能摘要 文件系统性能通常使用延迟、吞吐量和每秒 Input/Output 操作数 (IOPS) 等维度来衡量。Amazon EFS 在这些方面的性能取决于文件系统的配置。以下配置会影响 Amazon EFS 文件系统的性能： + **文件系统类型** – 区域性或单区 + **性能模式** – 通用或最大 I/O **重要** 与通用 I/O 性能模式相比，最大性能模式的每次操作延迟更高。为了提高性能，我们建议始终使用通用性能模式。有关更多信息，请参阅 [性能模式](#performancemodes)。 + **吞吐量模式** – 弹性、预配置或突增 下表概述了使用通用性能模式的文件系统的性能规格，以及不同文件系统类型和吞吐量模式的可能组合。 **使用通用性能模式的文件系统的性能规格** | 存储和吞吐量配置 | 延迟1 | 最大 IOPS | 最大吞吐量 | | --- |--- |--- |--- | | **文件系统类型** | ** 吞吐量模式** | **读取操作** | **写入操作** | **读取操作** | **写入操作** | **P er-file-system read** 2 | **P er-file-system writ** e 2 | **按客户端读取/写入** | | --- |--- |--- |--- |--- |--- |--- |--- |--- | | **区域性** | 弹性 | \$11 毫秒 (ms) | 大约 2.7 毫秒 (ms) | 900,000—2,500,000 3 | 500,000 **3** | 每秒 20—60 千兆字节 () GiBps | 1—5 GiBps | 每秒 1,500 兆字节 (4) MiBps | | --- |--- |--- |--- |--- |--- |--- |--- |--- | | **区域性** | 已预置 | 大约 1 毫秒 | 大约 2.7 毫秒 | 55,000 | 25000 | 3—10 GiBps | 1—3.33 GiBps | 500 MiBps | | --- |--- |--- |--- |--- |--- |--- |--- |--- | | **区域性** | 突增 | 大约 1 毫秒 | 大约 2.7 毫秒 | 35000 | 7,000 | 3—5 GiBps | 1—3 GiBps | 500 MiBps | | --- |--- |--- |--- |--- |--- |--- |--- |--- | | **单区** | 弹性、预配置、爆发 | 大约 1 毫秒 | 大约 1.6 毫秒 | 35000 | 7,000 | 3 GiBps 5 | 1 GiBps 5 | 500 MiBps | | --- |--- |--- |--- |--- |--- |--- |--- |--- | 1. 所示延迟值代表了最佳条件下的最佳性能。实际结果可能因网络、工作负载和系统因素而异。 1. 最大读取和写入吞吐量取决于 AWS 区域。如果吞吐量超过最大吞吐量，则需要增加吞吐量配额。 AWS 区域任何增加吞吐量的请求都将 case-by-case由 Amazon EFS 服务团队进行考虑。是否批准可能取决于工作负载类型。有关请求增加配额的更多信息，请参阅[Amazon EFS 限额](limits.md)。 1. 默认情况下，使用弹性吞吐量的文件系统可针对不频繁访问的数据，实现高达 90,000 次读取 IOPS；而针对频繁访问的数据，可以实现 250,000 次读取 IOPS 和 50,000 次写入 IOPS。如果您的工作负载需要更高 IOPS，您可以请求将这些数字增加高达 10 倍。有关更多信息，请参阅 [您可以提高的 Amazon EFS 配额](limits.md#soft-limits)。其它建议适用于实现最大 IOPS。有关更多信息，请参阅 [优化需要高吞吐量和 IOPS 的工作负载](performance-tips.md#recs-intensive-workloads)。 1. MiBps 对于使用弹性吞吐量并使用版本 2.0 或更高版本的 Amazon EFS 客户端（amazon-efs-utils 版本）或 Amazon EFS CSI 驱动程序（aws-efs-csi-driver）装载的文件系统，最大合并读写吞吐量为 1,500。对于所有其他文件系统，吞吐量限制为 500 MiBps。有关 Amazon EFS 客户端的更多信息，请参阅[安装 Amazon EFS 客户端](using-amazon-efs-utils.md)。 1. 使用突增吞吐量的单区域文件系统可以驱动与使用突发吞吐量的区域文件系统相同的 per-file-system读取和写入吞吐量（读取的最大读取量为 5，写入的最大读 GiBps 取量为 3 GiBps ）。 ## 存储类 Amazon EFS 存储类专为实现最有效的存储而设计，具体取决于用例。 + EFS 标准存储类使用固态驱动器 (SSD) 存储为频繁访问的文件提供最低延迟级别。该存储类为读取提供低至 1 毫秒的首字节延迟，写入的首字节延迟低至 2.7 毫秒。 + EFS 不频繁访问（IA）和 EFS 存档存储类可存储访问频率较低的数据，这些数据不需要频繁访问的数据所需的延迟性能。这些存储类提供的第一个字节延迟为数十毫秒。 有关 EFS 存储类的更多信息，请参阅 [EFS 存储类](features.md#storage-classes)。 ## 性能模式 Amazon EFS 提供两种性能模式：通用模式和最大 I/O 模式。 + **通用模式**的每次操作延迟最低，是文件系统的默认性能模式。单区文件系统始终使用通用性能模式。为了提高性能，我们建议始终使用通用性能模式。 + **Max I/O 模式**是上一代性能类型，专为高度并行化的工作负载而设计，这些工作负载可以容忍比通用模式更高的延迟。One Zone 文件系统或使用弹性吞吐量的文件系统不支持最大 I/O 模式。 **重要** 由于最大 I/O 的每次操作延迟较高，因此我们建议对所有文件系统使用通用性能模式。 为了帮助确保您的工作负载保持在使用通用性能模式的文件系统可用的 IOPS 限制范围内，您可以监控该`PercentIOLimit` CloudWatch 指标。有关更多信息，请参阅 [CloudWatch 亚马逊 EFS 的指标](efs-metrics.md)。 应用程序可以弹性扩展其 IOPS，以达到与性能模式相关的限制。无需单独为 IOPS 付费；它们已包含在文件系统的吞吐量核算中。每个网络文件系统（NFS）请求都以 4 千字节（KB）吞吐量或其实际请求和响应大小计算，以较大者为准。 ## 吞吐量模式 文件系统的吞吐量模式决定了文件系统可用的吞吐量。Amazon EFS 提供三种吞吐量模式：弹性、预配置和突增。读取吞吐量已打折，使您能够获得比写入吞吐量更高的读取吞吐量。每种吞吐量模式下可用的最大吞吐量取决于 AWS 区域。有关不同区域中最大文件系统吞吐量的更多信息，请参阅[Amazon EFS 限额](limits.md)。 文件系统可以实现 100% 的读写组合吞吐量。例如，如果文件系统使用其读取吞吐量限制的 33%，则该文件系统可以同时达到其写入吞吐量限制的 67%。可以在控制台的**文件系统详细信息**页面上的**吞吐量利用率（%）**图表中监控文件系统的吞吐量使用情况。有关更多信息，请参阅 [监控吞吐量性能](how_to_use_metrics.md#monitor-throughput-performance)。 ### 为文件系统选择正确的吞吐量模式 为文件系统选择正确的吞吐量模式取决于工作负载的性能要求。 + **弹性吞吐量**（推荐）— 当您的工作负载激增或不可预测且性能要求难以预测时，或者您的应用程序以 5% 或更低的 average-to-peak比率驱动吞吐量时，请使用默认的弹性吞吐量。有关更多信息，请参阅 [弹性吞吐量](#elastic)。 + **预配置吞吐量**-如果您知道工作负载的性能要求，或者当您的应用程序以 5% 或更高的 average-to-peak比例提高吞吐量时，请使用预配置吞吐量。有关更多信息，请参阅 [预配置吞吐量](#provisioned-throughput)。 + **突增吞吐量** – 如果您希望吞吐量随文件系统中的存储量扩展，请使用突增吞吐量。 如果在使用突增吞吐量后，发现您的应用程序受到吞吐量限制（例如，使用的吞吐量超过允许吞吐量的 80%，或者已经使用了所有突增点数），则应使用弹性吞吐量或预置吞吐量。有关更多信息，请参阅 [突增吞吐量](#bursting)。 有关 Amazon EFS 指标的更多信息，请参阅[CloudWatch 亚马逊 EFS 的指标](efs-metrics.md)。 ### 弹性吞吐量 对于使用弹性吞吐量的文件系统，Amazon EFS 会自动扩缩吞吐量性能，以满足工作负载活动需求。对于性能要求难以预测的尖峰或不可预测的工作负载，或者对于吞吐量以平均峰值吞吐量的 5% 或更低（ average-to-peak比率）的应用程序，弹性吞吐量是最佳吞吐量模式。 由于具有弹性吞吐量的文件系统的吞吐量性能会自动扩缩，因此无需指定或预置吞吐能力来满足应用程序需求。只需为读取或写入的元数据和数据量付费，并且在使用弹性吞吐量时不会累积或消耗突增点数。 **注意** 虽然 Elastic 吞吐量旨在根据您的吞吐量弹性扩展，但我们建议您通过使用 CloudWatch （计量IOBytes）监控指标和使用情况警报来实施适当的治理，以此作为最佳运营实践的一部分。这有助于保持资源的最优利用率，并确保始终保持在计划的操作参数范围内。有关更多信息，请参阅 [使用 Amazon 监控指标 CloudWatch](monitoring-cloudwatch.md)。 有关每个区域的弹性吞吐量限制的信息，请参阅[您可以提高的 Amazon EFS 配额](limits.md#soft-limits)。 ### 预配置吞吐量 使用预置吞吐量时，可以指定文件系统可以驱动的吞吐量级别，不受文件系统大小或突增点数余量影响。如果您知道工作负载的性能要求，或者您的应用程序将吞吐量提高到该 average-to-peak比率的 5% 或更多，请使用预配置吞吐量。 对于使用预置吞吐量的文件系统，会针对为文件系统启用的吞吐量向您收费。一个月内计费的吞吐量基于预配置的吞吐量，该吞吐量超过文件系统包含的标准存储的基准吞吐量，不超过 AWS 区域中现行的突增基准吞吐量限制。 如果文件系统的基准吞吐量超过预配置的吞吐量，则它会自动使用文件系统允许的突增吞吐量（不超过其中的现行突发基准吞吐量限制）。 AWS 区域 有关每个区域的预置吞吐量限制的信息，请参阅[您可以提高的 Amazon EFS 配额](limits.md#soft-limits)。 #### 突增吞吐量 对于需要吞吐量随文件系统存储量扩展的工作负载，建议使用突增吞吐量。使用突增吞吐量时，基本吞吐量与标准存储类中的文件系统大小成正比，每 GiB 存储空间的速率为 KiBps 每 GiB 存储 50。当文件系统消耗的吞吐量低于其基本吞吐量速率时，突增点数就会累积，当吞吐量超过基本速率时，会扣除突增点数。 当有突发积分可用时，文件系统可以在标准存储中将吞吐量提高到 MiBps每个 TiB 100（每 KiBps GiB 50 个），但不 AWS 区域 超过限制，最小值为 100。 MiBps如果没有可用的突发积分，则文件系统最多可以驱动 MiBps 每 TiB 存储 50 个，最少为 1。 MiBps 有关每个区域的突增吞吐量的信息，请参阅[General resource quotas that cannot be changed](limits.md#ResourceHardLimits)。 ##### 了解 Amazon EFS 突增点数 使用突增吞吐量，每个文件系统随时间推移获得基准速率的突增点数，该基准速率由存储在 EFS 标准存储类中的文件系统大小决定。基准速率为 MiBps 每 TiB [TiB] 存储 50 个（相当于每 KiBps GiB 存储 50 个）。Amazon EFS 可将读取操作计量到写入操作速率的三分之一，从而允许文件系统将基准速率提高到 KiBps 每 GiB 读取吞吐量 150，或每 KiBps GiB 写入吞吐量 50。 文件系统可以其基准计量速率持续提高吞吐量。每当文件系统处于不活动状态或吞吐量低于其基准计量速率时，文件系统就会累积突增点数。累计的突增积分使文件系统可以推高吞吐量，使其高于其基准速率。 例如，标准存储类中具有 100 GiB 计量数据的文件系统的基准吞吐量为 5。 MiBps****在 24 小时的非活动状态下，文件系统将获得价值 43.2 万MiB（5 MiB **× 86,400 秒 **=** 432,000 Mi** B）的积分，这些积分可用于以 100 的速度突发持续 72 分钟（432,000 MiB ε 100 MiBps = 72 分钟）。 MiBps **** 如果大于 1 TiB 的文件系统在 50% 的时间内处于不活动状态，该文件系统在其余 50% 的时间内始终可以突增。 下表提供了突增行为的示例。 **** | 文件系统大小 | 突增吞吐量 | 基准吞吐量 | | --- | --- | --- | | 标准存储中有 100 GiB 计量数据 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/efs/latest/ug/performance.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/efs/latest/ug/performance.html) | | 标准存储中有 1 TiB 计量数据 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/efs/latest/ug/performance.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/efs/latest/ug/performance.html) | | 标准存储中有 10 TiB 计量数据 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/efs/latest/ug/performance.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/efs/latest/ug/performance.html) | | 通常，较大的文件系统 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/efs/latest/ug/performance.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/efs/latest/ug/performance.html) | **注意** Amazon EFS 为所有文件系统提供的计量吞吐量为 1 MiBps ，即使基准速率较低。 确定基准速率和突增速率时所使用的文件系统大小是通过 [DescribeFileSystems](API_DescribeFileSystems.md) API 操作可用的 `ValueInStandard` 计量大小。 小于 1 TiB 的文件系统可以获得的积分可达到最高 2.1 TiB 积分余额，对于大于 1 TiB 的文件系统，可达到每 TiB 存储 2.1 TiB 的积分余额。此行为意味着文件系统可以累积足够的点数来持续突增长达 12 小时。 ### 对切换吞吐量和更改预置量的限制 可以切换现有文件系统的吞吐量模式并更改吞吐量。但是，在将吞吐量模式切换到预置吞吐量或更改预置吞吐量后，以下操作将在 24 小时内受到限制： + 从预置吞吐量模式切换到弹性或突增吞吐量模式。 + 减少预置吞吐量。 # Amazon EFS 性能提示 在使用 Amazon EFS 时，请记住以下性能提示。 ## 平均 I/O 大小 Amazon EFS 的分布式特性实现了高水平的可用性、持久性和可扩展性。这种分布式架构使得每次文件操作只产生很小的延迟开销。由于每次操作都有这种延迟，因此总体吞吐量通常会随着平均 I/O 大小的增加而增加，因为开销会分摊到较大的数据量上。 ## 优化需要高吞吐量和 IOPS 的工作负载 对于需要高吞吐量和 IOPS 的工作负载，请使用配置了通用性能模式和弹性吞吐量的区域性文件系统。 **注意** 要对频繁访问的数据实现最大次读取 IOPS，文件系统必须使用弹性吞吐量。 要实现最高级别的性能，必须通过按如下方式配置应用程序或工作负载来利用并行化。 1. 在所有客户端和目录之间均匀分配工作负载，目录数至少与使用的客户端数量相同。 1. 通过将各个线程与不同的数据集或文件对齐，最大限度地减少争用。 1. 将工作负载分配到 10 个或更多的 NFS 客户端，单个装载目标中每个客户端至少有 64 个线程。 ## 同时连接 您可以同时在多达数千个 Amazon EC2 和其他 AWS 计算实例上挂载 Amazon EFS 文件系统。如果可以跨更多实例并行执行应用程序，则可以在跨计算实例的聚合中提高文件系统的吞吐量级别。 ## 请求模型 如果启用对文件系统的异步写入，则待处理的写入操作会在 Amazon EC2 实例上缓冲，然后再异步写入 Amazon EFS。异步写入通常具有较低的延迟。在执行异步写入时，内核使用额外内存进行缓存。 启用了同步写入的文件系统或使用绕开缓存选项（例如 `O_DIRECT`）打开文件的文件系统将向 Amazon EFS 发出同步请求。每个操作都将在客户端和 Amazon EFS 之间往返一次。 **注意** 您选择的请求模型将在一致性（如果您使用多个 Amazon EC2 实例）和速率之间进行取舍。使用同步写入可以在处理下一个请求之前完成每个写入请求事务，从而提高数据一致性。使用异步写入可通过缓冲待处理的写入操作来提高吞吐量。 ## NFS 客户端挂载设置 确认您使用的是 [挂载 EFS 文件系统](mounting-fs.md) 和 [Linux 的挂载注意事项](mounting-fs-mount-cmd-general.md) 中推荐的挂载选项。 在 Amazon EC2 实例上挂载文件系统时，Amazon EFS 支持网络文件系统版本 4.0 和 4.1（NFSv4）协议。与 NFSv4.0（每秒少于 1 千个文件）相比，NFSv4.1 为并行小文件读取操作提供了更高的性能（每秒大于 1 万个文件）。对于运行 macOS Big Sur 的亚马逊 EC2 macOS 实例，仅 NFSv4支持 .0。 请勿使用以下挂载选项： + `noac`、`actimeo=0`、`acregmax=0`、`acdirmax=0` – 这些选项会禁用属性缓存，这会对性能产生非常大的影响。 + `lookupcache=pos`、`lookupcache=none` – 这些选项会禁用文件名查找缓存，这会对性能产生非常大的影响。 + `fsc` – 此选项启用本地文件缓存，但不会更改 NFS 缓存的一致性，也不会减少延迟。 **注意** 在挂载文件系统时，请考虑将 NFS 客户端的读写缓冲区大小增加到 1 MB。 ## 优化小文件性能 可以通过最大限度地减少文件重新打开次数、增加并行度，以及尽可能捆绑参考文件来提高小文件的性能。 + 尽量减少往返服务器的次数。 如果以后在工作流中需要文件，请不要不必要地关闭这些文件。保持文件描述符处于打开状态可以直接访问缓存中的本地副本。文件打开、关闭和元数据操作通常不能以异步方式或通过管道进行。 读取或写入小文件时，两次额外往返非常重要。 每次往返（文件打开、文件关闭）所花费的时间可能与读取或写入兆字节批量数据一样多。在计算作业开始时打开一次输入或输出文件，并在整个作业期间保持打开状态会更有效。 + 使用并行度来减少往返时间的影响。 + 将参考文件捆绑到 `.zip` 文件中。有些应用程序使用大量较小的主要是只读文件的参考文件。将这些文件捆绑到一个 `.zip` 文件中，只需一次打开-关闭往返操作即可读取多个文件。 `.zip` 格式允许随机访问单个文件。 ## 优化目录性能 在同时修改的超大目录（超过 10 万个文件）上执行列出操作（**ls**）时，Linux NFS 客户端可能会挂起而不返回响应。此问题已在内核 5.11 中修复，该内核已移植到 Amazon Linux 2 内核 4.14、5.4 和 5.10。 我们建议您在可能的情况下，将文件系统上的目录数保持在 1 万以内。尽可能多地使用嵌套子目录。 列出目录时，如果不需要文件属性，应避免获取这些属性，因为它们并未存储在目录本身中。 ## 优化 NFS read\$1ahead\$1kb 的大小 NFS `read_ahead_kb` 属性定义了 Linux 内核在顺序读取操作期间要提前读取或预取的千字节数。 对于 5.4.\$1 之前的 Linux 内核版本，`read_ahead_kb` 值是通过 `NFS_MAX_READAHEAD` 乘以 `rsize`（挂载选项中设置的客户端配置的读取缓冲区大小）的值来设置的。使用[推荐的挂载选项](mounting-fs-mount-cmd-general.md)时，此公式将 `read_ahead_kb` 设置为 15 MB。 **注意** 从 Linux 内核版本 5.4.\$1 开始，Linux NFS 客户端使用默认 `read_ahead_kb` 值 128 KB。我们建议将此值增加到 15 MB。 挂载文件系统后，`amazon-efs-utils` 版本 1.33.2 及更高版本中提供的 Amazon EFS 挂载帮助程序会自动将 `read_ahead_kb` 值修改为等于 15 \$1 `rsize` 或 15 MB。 对于 Linux 内核 5.4 或更高版本，如果不使用挂载帮助程序来挂载文件系统，请考虑手动将 `read_ahead_kb` 设置为 15 MB 以提高性能。挂载文件系统后，可使用以下命令重置 `read_ahead_kb` 值。在使用此命令之前，替换以下值： + 将 `read-ahead-value-kb` 替换为所需的大小（以千字节为单位）。 + 将 `efs-mount-point` 替换为文件系统的挂载点。 ``` device_number=$(stat -c '%d' efs-mount-point) ((major = ($device_number & 0xFFF00) >> 8)) ((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00))) sudo bash -c "echo read-ahead-value-kb > /sys/class/bdi/$major:$minor/read_ahead_kb" ``` 以下示例将 `read_ahead_kb` 大小设置为 15 MB。 ``` device_number=$(stat -c '%d' efs) ((major = ($device_number & 0xFFF00) >> 8)) ((minor = ($device_number & 0xFF) | (($device_number >> 12) & 0xFFF00))) sudo bash -c "echo 15000 > /sys/class/bdi/$major:$minor/read_ahead_kb" ``` # Amazon EFS 性能问题排查 通常，如果您遇到难以解决的 Amazon EFS 问题，请确认您使用的是最新 Linux 内核。如果使用的是企业 Linux 发行版，我们建议您使用以下版本： + 内核版本为 4.3 或更高版本的 Amazon Linux 2 + Amazon Linux 2015.09 或更高版本 + RHEL 7.3 或更高版本 + 所有 Ubuntu 16.04 版本 + 具有内核 3.13.0-83 或更高版本的 Ubuntu 14.04 + SLES 12 Sp2 或更高版本 如果使用其他发行版或自定义内核，我们建议您使用内核 4.3 或更高版本。 **注意** 由于[并行打开多个文件时，性能不佳](#open-close-operations-serialized)，RHEL 6.9 可能对于特定工作负载不够理想。 **Topics** + [ ## 无法创建 EFS 文件系统 ](#cant-create-filesystem) + [ ## 拒绝访问 NFS 文件系统上允许的文件 ](#nfs-16-group-limit) + [ ## 访问 Amazon EFS 控制台时出错 ](#efs-console-access-errors) + [ ## Amazon EC2 实例挂起 ](#ec2-instance-hangs) + [ ## 写入大量数据的应用程序挂起 ](#application-large-data-hangs) + [ ## 并行打开多个文件时，性能不佳 ](#open-close-operations-serialized) + [ ## 自定义 NFS 设置导致写入延迟 ](#custom-nfs-settings-write-delays) + [ ## 使用 Oracle Recovery Manager 创建备份的速度很慢 ](#oracle-backup-slow) ## 无法创建 EFS 文件系统 创建 EFS 文件系统的请求失败，并显示以下消息： ``` User: arn:aws:iam::111122223333:user/username is not authorized to perform: elasticfilesystem:CreateFileSystem on the specified resource. ``` **要采取的操作** 检查您的 AWS Identity and Access Management (IAM) 策略，确认您有权创建具有指定资源条件的 EFS 文件系统。有关更多信息，请参阅 [Amazon EFS 的身份和访问管理](security-iam.md)。 ## 拒绝访问 NFS 文件系统上允许的文件 当分配了超过 16 个访问组 IDs (GIDs) 的用户尝试在 NFS 文件系统上执行操作时，可能会拒绝他们访问文件系统上允许的文件。[之所以出现此问题， GIDs 是因为 NFS 协议支持 GIDs 每个用户最多 16 个，并且根据 RFC 5531 中的定义，NFS 客户端请求中的任何其他请求都会被截断。](https://www.rfc-editor.org/rfc/rfc5531) **要采取的操作** 重组您的 NFS 用户和组映射，以便为每个用户分配的访问组不超过 16 个（）。GIDs ## 访问 Amazon EFS 控制台时出错 本节介绍用户在访问 Amazon EFS 管理控制台时可能遇到的错误。 ### 对的 `ec2:DescribeVPCs` 凭证进行身份验证时出错 访问 Amazon EFS 控制台时会显示以下错误消息： ``` AuthFailure: An error occurred authenticating your credentials for ec2:DescribeVPCs. ``` 此错误表示您的登录凭证未成功通过 Amazon EC2 服务的身份验证。在您选择的 VPC 中创建 EFS 文件系统时，Amazon EFS 控制台会代表您调用 Amazon EC2 服务。 **要采取的操作** 确保正确设置了客户端访问 Amazon EFS 控制台的时间。 ## Amazon EC2 实例挂起 Amazon EC2 实例挂起的原因可能是，您在未首先卸载文件系统的情况下删除了文件系统挂载目标。 **要采取的操作** 在删除文件系统挂载目标之前，请卸载文件系统。有关卸载您的 Amazon EFS 文件系统的更多信息，请参阅[卸载文件系统](unmounting-fs.md)。 ## 写入大量数据的应用程序挂起 将大量数据写入 Amazon EFS 的应用程序挂起，并导致实例重新启动。 **要采取的操作** 如果应用程序需要太长时间才能将其所有数据写入 Amazon EFS，则 Linux 可能会重新启动，因为进程似乎已没有响应。两个内核配置参数可定义此行为，即 `kernel.hung_task_panic` 和 `kernel.hung_task_timeout_secs`。 在以下示例中，在实例重启之前，`ps` 命令将挂起的进程状态报告为 `D`，表明该进程正在等待 I/O。 ``` $ ps aux | grep large_io.py root 33253 0.5 0.0 126652 5020 pts/3 D+ 18:22 0:00 python large_io.py /efs/large_file ``` 要防止重新启动，请增加超时期限或禁用检测到挂起任务时的内核崩溃。以下命令将禁用大多数 Linux 系统上的挂起任务内核崩溃。 ``` $ sudo sysctl -w kernel.hung_task_panic=0 ``` ## 并行打开多个文件时，性能不佳 并行打开多个文件的应用程序不会体验到预期的并 I/O 行化性能提升。 **要采取的操作** 网络文件系统版本 4 (NFSv4) 客户端和使用 NFSv4 .1 的 RHEL 6 客户端上会出现此问题，因为这些 NFS 客户端会序列化 NFS 打开和关闭操作。请使用 NFS 协议版本 4.1 和建议的 [Linux 发行版](#recommend.linux.dist)（不存在此问题）之一。 如果您不能使用 NFSv4 .1，请注意 Linux NFSv4 .0 客户端会按用户 ID 和组对打开和关闭请求进行序列化。 IDs即使多个进程或多个线程同时发出请求，也会发生此序列化。当所有操作都 IDs 匹配时，客户端一次只向 NFS 服务器发送一个打开或关闭操作。要解决这些问题，可以执行下列任一操作： + 您可以在同一 Amazon EC2 实例上通过不同用户 ID 运行每个进程。 + 您可以让所有未处理 IDs 的请求中的用户保持不变，改为修改群组 IDs 集。 + 您可以从单独的 Amazon EC2 实例运行每个进程。 ## 自定义 NFS 设置导致写入延迟 您可以自定义 NFS 客户端设置，Amazon EC2 实例需要最多三秒钟时间来查看通过其他 Amazon EC2 实例对文件系统执行的写入操作。 **要采取的操作** 如果遇到该问题，可以通过以下任一方法加以解决： + 如果 Amazon EC2 实例上读取数据的 NFS 客户端已激活属性缓存，请卸载文件系统。然后，使用 `noac` 选项重新挂载文件系统以禁用属性缓存。默认情况下， NFSv4.1 中的属性缓存处于启用状态。 **注意** 禁用客户端缓存可能会降低您的应用程序性能。 + 您还可以通过使用与 NFS 过程兼容的编程语言来按需清除您的属性缓存。要执行该操作，您可以在发送 `ACCESS` 过程请求后立即发送读取请求。 例如，您可以使用 Python 编程语言构造以下调用。 ``` # Does an NFS ACCESS procedure request to clear the attribute cache, given a path to the file import os os.access(path, os.W_OK) ``` ## 使用 Oracle Recovery Manager 创建备份的速度很慢 如果在启动备份作业之前 Oracle Recovery Manager 暂停 120 秒，使用 Oracle Recovery Manager 创建备份的速度可能很慢。 **要采取的操作** 如果遇到该问题，请禁用 Oracle 直接 NFS，如 Oracle 帮助中心的[启用和禁用 NFS 的直接 NFS 客户端控制](https://docs.oracle.com/database/122/HPDBI/enabling-and-disabling-direct-nfs-client-control-of-nfs.htm)中所述。 **注意** Amazon EFS 不支持 Oracle 直接 NFS。 # 排查 AMI 和内核问题 下文介绍了如何排查在从 Amazon EC2 实例使用 Amazon EFS 时遇到的与特定亚马逊机器映像（AMI）或内核版本相关的问题。 **Topics** + [ ## 无法更改所有权 ](#chown-kernal) + [ ## 由于客户端错误，文件系统重复执行操作 ](#file-system-stuck-client-bug) + [ ## 客户端发生死锁 ](#deadlocked-client) + [ ## 列出大型目录中的文件需要很长时间 ](#long-time-listing) ## 无法更改所有权 您无法 file/directory 使用 Linux `chown` 命令更改的所有权。 **出现该错误的内核版本** 2.6.32 **要采取的操作** 您可以执行以下操作以解决该错误： + 如果要运行 `chown` 以执行更改 EFS 根目录所有权所需的一次性设置步骤，您可以从运行较新内核的实例中运行 `chown` 命令。例如，使用最新版本的 Amazon Linux。 + 如果 `chown` 是您的生产工作流程的一部分，则您必须更新内核版本才能使用 `chown`。 ## 由于客户端错误，文件系统重复执行操作 由于某个客户端错误，文件系统重复执行操作。 **要采取的操作** 将客户端软件更新为最新版本。 ## 客户端发生死锁 客户端变为死锁状态。 **出现该错误的内核版本** + 内核为 Linux 3.10.0-229.20.1.el7.x86\$164 的 CentOS-7 + 内核为 Linux 4.2.0-18-generic 的 Ubuntu 15.10 **要采取的操作** 请执行以下操作之一： + 升级为更新的内核版本。对于 CentOS-7，内核版本 **Linux 3.10.0-327** 或更高版本中包含相应的修复程序。 + 降级为较旧的内核版本。 ## 列出大型目录中的文件需要很长时间 如果在您的 NFS 客户端遍历目录以完成列出操作时，目录正在发生更改，则可能会出现这种情况。每当 NFS 客户端在这种遍历期间注意到目录内容发生更改时，它都会从头开始重新遍历。因此，对于包含经常更改的文件的大型目录，ls 命令可能需要很长时间才能完成。 **出现该错误的内核版本** 低于 2.6.32-696.el6 的 CentOS 和 RHEL 内核版本 **要采取的操作** 要解决该问题，请升级到较新的内核版本。