我有一个大的多用户系统，NFS安装了一大块共享存储。 我可以确定所有networkingstream量的来源 – 缩小到一个特定的主机 – 感谢nfsstat 。
然而，我仍然在追查哪些用户正在做这件事情有点困难 – 有几百个，在进程列表中没有任何明显的罪魁祸首。 （我通常从查找实例开始）
但是，我们肯定会有2.5k IOPS来自它，并导致主机上的资源问题。
有人能够提供我的build议，找出罪魁祸首进程/用户？
Box是一个RedHat Linux，与NetApp文件pipe理器交谈。
假设确实有一个罪魁祸首（单个用户）负责大部分2.5k IOPS：
我会从头开始 – 以这种速度，你应该看到一个或几个用户和进程突出在框中的活动进程，大多是睡觉，但也经常处于就绪状态 – 我会按i （隐藏不活动进程），然后按住空格键进行非常快速的更新。
我会单独列出出现频率更高的用户，只显示他们的进程以获得更稳定的视图。
如果您看到来自同一用户的许多进程（例如，在NFS上执行的复杂构build），请检查该用户的进程树以确认pstree -ps <user> 。 可能很难certificate这样的过程收集是除了通过启动/停止并观察netapp方面活动变化的相关性之外的原因。
如果罪魁祸首是一个单一的过程，我希望这将是一个稳定的存在在top产出。 除了find我也寻找：
但它也可能是完全自定义的东西，你不会find它“名义”。
这个速度还有可能是那么多用户（NFS服务器持有他们的本地和/或共享的项目分区）的共同作用 – – 你可以做的事情不多 – 也许有时间扩大NFS存储？
也许一个很好的提示是找出用户有多less打开的NFS文件（从客户端）。
我会使用lsof -N 。 这一个class轮可能会帮助你：
for user in $(who|awk '{print $1}'|sort -n|uniq); do echo $user ; lsof -N -u $user -a |wc -l; done
有一个伟大的工具wireshark。 有了它的terminal版本，tshark，你可以find客户端和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。 收集数据一些分钟，然后你可以使用你最喜欢的工具来find顶级用户：
$ cat nfs-capture.txt | sort -n -k 7 | uniq -c