![尝试列出内部文件时,Amazon EFS 会挂起](https://linux22.com/image/713556/%E5%B0%9D%E8%AF%95%E5%88%97%E5%87%BA%E5%86%85%E9%83%A8%E6%96%87%E4%BB%B6%E6%97%B6%EF%BC%8CAmazon%20EFS%20%E4%BC%9A%E6%8C%82%E8%B5%B7.png)
在 Amazon EFS 挂载点内执行 ls 时,它会挂起。
AWS 上的 EFS 故障排除部分EFS 故障排除
提到以下内容:
安装没有响应
Amazon EFS 挂载似乎无响应。例如,ls 等命令挂起。
采取的行动
如果另一个应用程序正在向文件系统写入大量数据,则可能会发生此错误。对正在写入的文件的访问可能会被阻止,直到操作完成。通常,任何试图访问正在写入的文件的命令或应用程序都可能挂起。例如,ls 命令在到达正在写入的文件时可能会挂起。这是因为某些 Linux 发行版为 ls 命令设置了别名,以便它除了列出目录内容外,还检索文件属性。
要解决此问题,请验证另一个应用程序是否正在将文件写入 Amazon EFS 挂载,以及它是否处于不间断睡眠 (D) 状态,如以下示例所示:
$ 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
确认情况属实后,您可以通过等待其他写入操作完成或实施变通方法来解决问题。在 ls 示例中,您可以直接使用 /bin/ls 命令,而不是使用别名,这样命令就可以继续执行,而不会挂起正在写入的文件。一般来说,如果写入数据的应用程序可以定期强制刷新数据(可能通过使用 fsync(2)),这可能有助于提高文件系统对其他应用程序的响应能力。但是,这种改进可能会以应用程序写入数据时的性能为代价。
因此我检查了一下是否有东西在写入,但唯一显示的是
根 43556 0.0 0.0 124356 756 pts/6D+19:15 0:00 ls --color=auto /efs/
root 43558 0.0 0.0 112664 972 pts/3 S+ 19:16 0:00 grep --color=auto efs
因此据我所知,没有任何东西被写入 EFS。还有其他什么原因可以让我调查吗?
我还尝试在单独的机器上安装 EFS 只是为了验证,我还测试了不同 AZ 中的另一台机器与该 AZ 中的另一个安装点,看到了相同的行为。
更新:
lsof 显示:
nfsv4.1-s 113422根cwd DIR 202,1 4096 128 /
nfsv4.1-s 113422 根 rtd DIR 202,1 4096 128 /
nfsv4.1-s 113422 txt cwd 未知 /proc/113422/exe
卸载时它会消失,安装后它会重新出现。
答案1
鉴于之前的所有信息,很难确切地说出发生了什么。但是,您需要 Amazon EFS 挂载才能工作,因此:
您的lsof
结果显示 /proc 文件系统中可能存在伪文件。在某个时候,该进程丢失了可执行文件,我怀疑它正在尝试继续运行。卸载时它会消失,因为 lsof 命令看不到卷,而重新安装时,该命令会再次看到丢失的可执行文件。这可能是正在消耗资源的进程。当您运行命令时ps
,您是否看到进程 113422?由于您没有报告另一个应用程序正在运行,因此您可以尝试终止此进程。
首先,我会运行ps -aux
以查看所有正在运行的进程,包括后台进程,并查看是否可以找到进程 113422。如果可以,它正在运行什么?(或者认为它正在运行。)如果您愿意停止该进程,则运行kill -9 113422
并完全停止它。
重新尝试 ls 命令,它应该可以正常运行。您也可以/bin/ls
直接使用该命令。事实上,由于您有这么多小文件,我建议只使用此方法,这样系统就不会因为等待文件而挂起。
至于性能,从你的评论来看,你选择 EFS 是因为文件系统大小不受限制,所以 EBS 可能不是一个选择,尽管它可以提供更好的性能。每种类型都有自己的优点和缺点。但是,如果您继续遇到问题,也许重新审视文件系统决策会有所帮助。