为什么 file-nr 和 lsof 对打开文件的计数不同?

为什么 file-nr 和 lsof 对打开文件的计数不同?

我突然遇到了一个问题;我的所有应用程序和服务器都运行良好,突然我看到打开的文件数量猛增。

我正在用这个命令检查它:

cat /proc/sys/fs/file-nr

当我检查它时,它显示44544 0 128000,所以 44544 是打开文件的数量。

但是当我检查这个命令时 -lsof | wc -l 它显示 - 28384。

那么哪一个是正确的呢?

我的最大打开文件数限制是 65535

ulimit -a
open files                      (-n) 65535

我想知道使用更多打开文件的前 5 个进程。我可以从中得到这个lsof,但这里显示的计数与我上面提到的其他命令非常不同。

我可以获取此命令统计的进程的详细信息吗cat /proc/sys/fs/file-nr

根据下面提到的链接,它说我们不能, 如何显示打开的文件描述符但不使用 lsof 命令

我有解决办法吗?我需要找到哪个进程突然开始使用更多打开的文件。

更新 抱歉给大家带来麻烦了。我发现我正在做的错误是我没有从根目录检查 lsof|wc -l 。这就是我看到巨大差异的原因。

file -nr 和 lsof 的输出之间仍然存在差异 | wc -l(从根目录)。 lsof 计数大于 file -nr 计数。原因是, file -nr 忽略了一些目录(lsof 将其视为文件),我通过对 google 本身的一些研究发现了这个原因。无论如何!感谢大家的帮助!

答案1

这里似乎有两个问题。首先,file-nr 和 file-max 结构的完整文档可以在以下位置找到:

https://www.kernel.org/doc/Documentation/sysctl/fs.txt

这将该文件中的字段定义为:

file-nr 中的三个值分别表示已分配的文件句柄数、已分配但未使用的文件句柄数以及最大文件句柄数。 Linux 2.6 总是报告 0 作为空闲文件句柄的数量——这不是一个错误,它只是意味着分配的文件句柄的数量与已使用的文件句柄的数量完全匹配。

希望这已经足够清楚了。第二个问题已经在上面提到的线程中得到了回答(https://serverfault.com/questions/485262/number-of-file-descriptors- Different- Between-proc-sys-fs-file-nr-and-proc-pi)并且似乎转移到

  1. 如果您需要获得进程使用的文件描述符的良好近似值,请“使用 lsof”并适当过滤输出,或者,
  2. 遍历 /proc 文件系统(并且仍然必须过滤输出)以便及时获取文件描述符使用的快照。

获得准确的指标非常困难,因为在任何给定点使用的 FD 数量在系统上可能会发生非常迅速的波动。

以下线程建议了“lsof”方法的过滤方案:

https://serverfault.com/questions/396872/why-or-how-does-the-number-of-open-file-descriptors-in-use-by-root-exceed-ulim

相关内容