EFS NFS 在 LIST 操作上的性能

EFS NFS 在 LIST 操作上的性能

我在 FTP 服务器上安装了 AWS EFS 驱动器。我偶尔会发现性能变得非常差的问题。公共目录有大约 10,000 个小文本文件,在流量大(约 30-40 个并发用户)的情况下,FTP LIST 操作会挂起。即使在这些时候在同一目录中的 Linux 终端中执行 ls 命令也很慢。对相关 proftp 进程和 ls 命令进行 Strace 都显示它卡在 getdents 系统调用处。

备用 FTP 服务器安装了相同的驱动器,当我在此目录中执行移动命令来存档其中一些 10k 文件时,我注意到主 FTP 服务器在 LIST 操作处挂起,而备用服务器正在执行移动操作。

服务器和 EFS 驱动器上的所有指标都表明资源完全在限制范围内。当 LIST 操作在主 FTP 服务器上挂起时,CPU 处于 99% 空闲状态,cpu wa 可以忽略不计。所有 proftp 子进程都进入 D 不间断睡眠状态,等待 getdents 返回 10,000 个目录列表。

EFS 指标显示突发信用、吞吐量、总 I/O 等没有问题。

虽然设计不太好,但这是我无法改变的,因为它是客户端系统。在负载测试中,它显示能够处理 60 个并发用户执行 LIST 操作。我倾向于认为一些用户正在写入目录,这阻止了 LIST 操作完成。我知道一些操作系统错误会使 EFS/NFS 操作串行而不是并行,但使用修补版本的 Amazon Linux 应该不会出现问题,因为它是完全最新的,这些错误不适用。EFS 是根据 AWS 默认设置安装的,例如 nfs 硬安装等

令人费解的是,为什么性能有时会从非常合理变为缓慢,而流量模式没有任何明显差异。我不会想到,在单独的服务器上执行写入/移动操作会挂起另一台服务器上的 LIST 操作,尽管它们位于同一目录中。当我不移动文件时也会发生这种情况,但我怀疑这是因为某些用户正在写入目录。

如果您以前见过类似的 NFS 问题,我们将非常感激您的任何想法。

相关内容