☰

查找导致 NFS 挂载失败的用户

tag-icon • tag-icon linux nfs
查找导致 NFS 挂载失败的用户

我有一个大型多用户系统，NFS 安装了大量共享存储。借助 ，我可以识别所有网络流量的来源 - 并将其缩小到特定主机nfsstat。

然而，我仍然有点难以追踪哪个的用户正在这样做——有几百个，而且没有任何明显的进程列表中的罪魁祸首。（我通常从寻找实例开始find）

但我们确实有 2.5k IOPS 来自它，而且它导致了主机的资源问题。

有人能给我提供建议来找出罪魁祸首流程/用户吗？

Box 是 RedHat Linux，正在与 NetApp 文件服务器通信。

答案1

假设确实有一个罪魁祸首（单个用户）对 2.5k IOPS 的大部分负责：

我会首先top- 按照这个速率，您应该会看到一个或几个用户和进程在盒子上的活动进程中脱颖而出，大多数处于休眠状态，但也经常处于就绪状态 - 我会按i（隐藏非活动进程），然后按住空格键进行非常快速的更新。

我会挑选出出现频率更高的用户并仅显示他们的流程top以获得更稳定的视图。

如果您看到来自同一用户的许多进程（例如，在 NFS 上执行的复杂构建） - 请检查该用户的进程树以确认pstree -ps <user>。除了启动/停止它并观察 netapp 端活动变化的相关性之外，可能很难证明这种进程收集是原因。

如果罪魁祸首是一个单一进程，我预计它会在top输出中持续存在。此外，find我还会寻找：

  • rsync、dd、cp、rcp、scp、tar、备份解决方案等。
  • 典型的高级编程解释器：python、java 等（运行自定义脚本）
  • 网络/数据库应用程序
  • CI/QA 系统（如果服务器涉及软件开发）

但它也可能是完全定制的东西，你无法“按名字”找到它。

该速率也可能是如此多用户的集体效应（NFS 服务器是否保存了他们的主目录和/或共享项目分区？） - 你对此无能为力 - 也许是时候扩大 NFS 存储了？

答案2

也许一个很好的提示是找出用户打开了多少个 NFS 文件（从客户端）。

我会用lsof -N。这个一行代码可能会对你有帮助：

for user in $(who|awk '{print $1}'|sort -n|uniq); do echo $user ; lsof -N -u $user -a |wc -l; done

答案3

有一个很棒的工具 wireshark 。使用它的终端版本 tshark，你可以找到客户端和 uid：

$ tshark -i any -Y 'rpc.msgtyp == 0' -f 'port 2049' -Tfields -e frame.time -e ip.src -e nfs.main_opcode -e rpc.auth.uid

您将获得类似如下的输出：

Jun 23, 2015 11:41:13.306857000 aaa.bbb.ccc.ddd 9   0

带有时间戳、客户端 IP、nfs 操作和 uid。收集几分钟的数据，然后您可以使用您最喜欢的工具来查找顶级用户：

$ cat nfs-capture.txt | sort -n -k 7 | uniq -c

相关内容