Amazon EFS 故障排除:一般问题 - Amazon Elastic File System
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

Amazon EFS 故障排除:一般问题

使用该信息解决一般 Amazon EFS 问题。有关性能的信息,请参阅 Amazon EFS 性能

通常,如果您遇到难以解决的 Amazon EFS 问题,请确认您使用的是最新 Linux 内核。如果使用的是企业 Linux 发行版,我们建议您使用以下版本:

  • 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 或更高版本。

注意

由于并行打开多个文件时,性能不佳,RHEL 6.9 可能对于特定工作负载不够理想。

Amazon EC2 实例挂起

Amazon EC2 实例挂起的原因可能是,您在未首先卸载文件系统的情况下删除了文件系统挂载目标。

要采取的操作

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

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

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

措施

如果应用程序需要太长时间才能将其所有数据写入 Amazon EFS,则 Linux 可能会重新启动,因为进程似乎已没有响应。两个内核配置参数可定义此行为,即 kernel.hung_task_panickernel.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 OPEN 和 CLOSE 操作。请使用 NFS 协议版本 4.1 和建议的 Linux 发行版(不存在此问题)之一。

如果无法使用 NFSv4.1,请注意,Linux NFSv4.0 客户端按用户 ID 和组 ID 序列化打开和关闭请求。即使多个进程或多个线程同时发出请求,也会发生此序列化。仅当所有 ID 均匹配时,客户端才一次向 NFS 服务器发送一个打开或关闭操作。要解决这些问题,可以执行下列任一操作:

  • 您可以在同一 Amazon EC2 实例上通过不同用户 ID 运行每个进程。

  • 您可以对所有打开请求使用相同的用户 ID,并修改组 ID 集。

  • 您可以从单独的 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 客户端控制中所述。

注意

Amazon EFS 不支持 Oracle 直接 NFS。