对亚马逊EFS绩效问题进行故障排除 - Amazon Elastic File System
无法创建EFS文件系统拒绝访问文件系统上允许的NFS文件访问 Amazon EFS 控制台时出错Amazon EC2 实例挂起写入大量数据的应用程序挂起并行打开多个文件时，性能不佳导致写入延迟的自定义NFS设置使用 Oracle Recovery Manager 创建备份的速度很慢

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

对亚马逊EFS绩效问题进行故障排除

通常，如果您在使用 Amazon 时遇到问题EFS而无法解决，请确认您使用的是最新的 Linux 内核。如果使用的是企业 Linux 发行版，我们建议您使用以下版本：

  • 内核版本为 4.3 或更高版本的 Amazon Linux 2

  • Amazon Linux 2015.09 或更高版本

  • RHEL7.3 或更高版本

  • 所有 Ubuntu 16.04 版本

  • 具有内核 3.13.0-83 或更高版本的 Ubuntu 14.04

  • SLES12 Sp2 或更高版本

如果使用其他发行版或自定义内核，我们建议您使用内核 4.3 或更高版本。

注意

RHEL由于以下原因，6.9 可能不适合某些工作负载。并行打开多个文件时，性能不佳

无法创建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。

拒绝访问文件系统上允许的NFS文件

当分配了超过 16 个访问组 IDs (GIDs) 的用户尝试对NFS文件系统执行操作时，可能会拒绝他们访问文件系统上允许的文件。出现此问题的原因是，该NFS协议支持GIDs每个用户最多 16 个，并且任何其他请求GIDs都将从NFS客户端请求中截断，如 5531 中所RFC定义。

要采取的操作

重组您的NFS用户和组映射，以便为每个用户分配的访问组不超过 16 个（）GIDs。

访问 Amazon EFS 控制台时出错

本节介绍用户在访问 Amazon EFS 管理控制台时可能遇到的错误。

对的 ec2:DescribeVPCs 凭证进行身份验证时出错

访问 Amazon EFS 控制台时会显示以下错误消息：

AuthFailure: An error occurred authenticating your credentials for ec2:DescribeVPCs.

此错误表示您的登录凭证未成功通过 Amazon EC2 服务进行身份验证。在您选择的中创建EFS文件系统时，Amazon EFS 控制台会代表您调用 Amazon EC2 服务。VPC

要采取的操作

确保正确设置了客户端访问 Amazon EFS 控制台的时间。

Amazon EC2 实例挂起

Amazon EC2 实例可能会挂起，因为您在没有先卸载文件系统的情况下删除了文件系统挂载目标。

要采取的操作

在删除文件系统挂载目标之前，请卸载文件系统。有关卸载 Amazon EFS 文件系统的更多信息，请参阅卸载文件系统。

写入大量数据的应用程序挂起

向 Amazon 写入大量数据的应用程序EFS挂起并导致实例重启。

要采取的操作

如果应用程序需要很长时间才能将其所有数据写入 AmazonEFS，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客户端会进行序列NFSOPEN化和CLOSE操作。使用NFS协议版本 4.1 和一个不存在此问题的建议的 Linux 发行版。

如果您不能使用 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 Direct。NFS NFS

注意

亚马逊EFS不支持 Oracle Direct NFS。