我们运行一个cassandra集群，每个主机在任何时候都会打开几十万个文件。 我们希望能够定期获得打开文件的计数，并将这个数字填入石墨中，但是当我们在collectd下运行lsof时，最终需要花费几分钟的时间完成并咀嚼过多的CPU与此同时。 我想知道是否有一个替代和更友好的方式获得相同的数据，LSF提供，甚至是一种运行ISS，不会吃进CPU显着的方式？ （虽然我认为后一种方法可能需要更长的时间来完成比现在…不理想）。
也许内核维护一些包含打开文件数量的variables？ 妄想？
更新：在答复的答案之一，我们已经使用-b和-n标志。 下面是完整的命令，因为我在collectd下运行它： sudo lsof -b -n -w | stdbuf -i0 -o0 -e0 wc -l sudo lsof -b -n -w | stdbuf -i0 -o0 -e0 wc -l
您可能不需要parsing套接字的networking地址，所以至less使用-n开关。 那么你可能也想用-b跳过阻塞操作。
这两个第一个开关应该真的让它更快。
然后-l避免解决uid。 和-L以避免计数链接。 等等看到那个男人 。
或者，使用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之前，内核分配的文件会dynamic地处理，但是并没有再次释放它们。 相反，免费的文件句柄保存在重新分配的列表中; “自由文件句柄”值表示该列表的大小。 大量的空闲文件句柄表示在打开文件句柄的使用中出现了过去的高峰。 从Linux 2.6开始，内核会释放释放的文件句柄，“自由文件句柄”的值始终为零。
第一个价值，如果你是猫，它会给你准确的东西。
为了logging，我甚至无法让lsof输出匹配它，即使有一些欺骗，但我收集，如果这就是内核说，它比你从lsof得到的列表更权威。