本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 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.
```
**要采取的操作**
检查您的 Amazon 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。