lsof的非cpu密集型替代方案？

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

我们希望能够定期获取打开文件的数量并将其输入到石墨中，但是当我们lsof在collectdWindows XP 下运行时，它需要花费几分钟才能完成，并消耗大量CPU。 。

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

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

更新：

为了回答其中一个问题，我们已经在使用-band -n标志。这是我在以下命令下运行的完整命令collectd：

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

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

这两个第一个开关应该确实可以使它更快。

然后-l避免解决uid。并-L避免计算链接。等等，见男子lsof。

另外，在Linux中，您可以制作一个脚本来简单地计算下的链接，/proc/<PID>/fd如下所示：

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

你这样做是错的。

从 man proc

   /proc/sys/fs/file-nr

该（只读）文件包含三个数字：已分配文件句柄的数量（即当前打开的文件数量）；空闲文件句柄的数量；和最大文件句柄数（即，与/ proc / sys / fs / file-max相同的值）。如果分配的文件句柄数量接近最大值，则应考虑增加最大值。在Linux 2.6之前，内核分配的文件是动态处理的，但是并没有再次释放它们。而是将免费文件句柄保留在列表中以进行重新分配。“免费文件句柄”值指示该列表的大小。大量的免费文件句柄表明打开文件句柄的使用已达到峰值。从Linux 2.6开始，内核会释放释放的文件句柄，并且“

如果第一个值是cat，它将精确显示您所要获得的结果。

为了记录lsof，即使经过一定程度的伪造，我也无法获得与之匹配的输出，但是我收集的是内核说它比您从列表中得到的列表更具权威性的内容lsof。