lsof 的非 CPU 密集型替代品？

Question

我们运行一个Apache Cassandra集群，其中每个主机在任何给定时间都有几十万个文件打开。

我们希望能够定期获取打开文件的数量并将这个数字输入到Graphite 中，但是当我们在 Graphitelsof下运行时collectd，它最终需要几分钟才能完成并同时消耗过多的 CPU .

我想知道是否有另一种更友好的方式来获取 lsof 提供的相同数据，或者甚至是一种运行 lsof 的方法，它不会明显地占用 CPU？（虽然我认为后一种方法可能需要比目前更长的时间才能完成......并不理想）。

也许内核在某处维护了一些包含打开文件数的变量？妄想？

更新：

作为对其中一个答案的回应，我们已经在使用-b和-n标志。这是我在下面运行的完整命令collectd：

sudo lsof -b -n -w | stdbuf -i0 -o0 -e0 wc -l

Answer 1

您可能不需要解析套接字的网络地址，因此至少使用-n开关。那么你可能还想跳过阻塞操作-b。

这两个第一个开关应该真的让它更快。

然后-l避免解析uid。并-L避免计算链接。等等。参见man lsof。

或者，使用 Linux，您可以编写一个脚本来简单地计算如下链接/proc/<PID>/fd：

find /proc -mindepth 3 -maxdepth 3 -type l | awk -F/ '$4 == "fd" { s++ } END { print s }'

Answer 2

你这样做是错的。

从 man proc

   /proc/sys/fs/file-nr

这个（只读）文件包含三个数字：分配的文件句柄数（即当前打开的文件数）；空闲文件句柄的数量；和最大文件句柄数（即与 /proc/sys/fs/file-max 相同的值）。如果分配的文件句柄数接近最大值，则应考虑增加最大值。在 Linux 2.6 之前，内核会动态分配文件句柄，但不会再次释放它们。相反，空闲文件句柄保存在一个列表中以供重新分配；“空闲文件句柄”值表示该列表的大小。大量的空闲文件句柄表明打开文件句柄的使用量过去曾达到高峰。从 Linux 2.6 开始，内核会释放释放的文件句柄，并且“

第一个值，如果你是猫，它会在它出现后准确地给出你的样子。

为了记录lsof，即使进行了一些捏造，我也无法获得与它匹配的输出，但是我收集内核所说的内容是否比您从中获得的列表更权威lsof。