Linux VFS:已达到文件最大限制1231582

我正在运行Linux2.6.36内核，我看到一些随机错误。诸如此类

ls: error while loading shared libraries: libpthread.so.0: cannot open shared object file: Error 23

是的，我的系统无法始终运行“ls”命令：(

我注意到dmesg输出中有几个错误：

# dmesg | tail
[2808967.543203] EXT4-fs (sda3): re-mounted. Opts: (null)
[2837776.220605] xv[14450] general protection ip:7f20c20c6ac6 sp:7fff3641b368 error:0 in libpng14.so.14.4.0[7f20c20a9000+29000]
[4931344.685302] EXT4-fs (md16): re-mounted. Opts: (null)
[4982666.631444] VFS: file-max limit 1231582 reached
[4982666.764240] VFS: file-max limit 1231582 reached
[4982767.360574] VFS: file-max limit 1231582 reached
[4982901.904628] VFS: file-max limit 1231582 reached
[4982964.930556] VFS: file-max limit 1231582 reached
[4982966.352170] VFS: file-max limit 1231582 reached
[4982966.649195] top[31095]: segfault at 14 ip 00007fd6ace42700 sp 00007fff20746530 error 6 in libproc-3.2.8.so[7fd6ace3b000+e000]

显然，file max错误看起来可疑，聚集在一起并且是最近的

# cat /proc/sys/fs/file-max
1231582
# cat /proc/sys/fs/file-nr
1231712 0       1231582

这对我来说也有点奇怪，但问题是，我不可能在这个系统上打开120万个文件。我是唯一使用它的人，本地网络之外的任何人都看不到它

# lsof | wc
  16046  148253 1882901
# ps -ef | wc 
    574    6104   44260

我看到一些文件说：

文件最大值和文件编号：

内核动态地分配文件句柄，但是它还没有释放它们

file max中的值表示Linux内核将分配的最大文件句柄数。当您收到大量关于文件句柄用完的错误消息时，您可能希望增加此限制

从历史上看，file nr中的三个值表示分配的文件句柄数、分配但未使用的文件句柄数和最大文件句柄数。Linux 2.6始终将0报告为可用文件句柄数——这不是错误，它只是意味着分配的文件句柄数与此数完全匹配使用过的文件句柄的数目

试图分配比printk报告的文件最大值更多的文件描述符，请查找“VFS:已达到文件最大值限制”

我的第一次阅读是内核基本上有一个内置的文件描述符泄漏，但我发现这很难相信。这意味着任何正在使用的系统都需要经常重新启动以释放文件描述符。正如我所说的，我不相信这是真的，因为Linux系统保持正常运行对我来说是正常的一次几个月（甚至几年）。另一方面，我也不敢相信我的近乎空闲的系统能保存超过一百万个打开的文件

有人对修复或进一步诊断有什么想法吗？当然，我可以重新启动系统，但我不希望这成为每隔几周就会出现的问题。作为权宜之计，我已经退出Firefox，Firefox占据了近2000行lsof输出（！）虽然我只打开了一个窗口，现在我可以再次运行“ls”，但我怀疑这是否能长期解决问题。（编辑：哎呀，我说得太快了。当我输入完这个问题时，症状又出现了）

---

提前感谢您的帮助。

我不喜欢留下问题，所以请为发现此问题的任何人提供摘要

结果我把问题重新发到了服务器故障上

事实上，他们什么都想不出来，但我做了更多的调查，最终发现这是NFSv4的真正缺陷，特别是服务器端锁定代码。我有一个NFS客户端，它每5秒钟运行一次监视脚本，使用rrdtool将一些数据记录到NFS装载的文件中。每次运行时，它都会锁定该脚本（加上另一个运行频率较低的脚本）导致每小时消耗约900个打开的文件，两个月后，它达到了极限

有几种可能的解决方案： 1） 改用NFSv3。 2） 停止运行监视脚本。 3） 将监视结果存储在本地而不是NFS上。 4） 等待修复此问题的NFSv4补丁（Bruce Fields实际上向我发送了一个补丁供我尝试，但我没有时间）

我相信你可以想出其他可能的解决办法

---

谢谢你的尝试。

嗯，我不知道那件事。谢谢你的指点，我将在那里发布。那些文档看起来并不准确，分配和释放文件句柄。不过，听起来你确实在某个地方有漏洞，我不知道如何最好地追踪它。你有没有内核中的“奇怪”东西？i、 e.您是否正在运行任何实验性的或不寻常的模块，或者任何可能导致内核本身打开（并且错误地不关闭）文件句柄的操作？与以前版本的ext相比，ext4非常不可靠。只需返回到ext3…5）使用不同的NFS服务器，可能是中的测试服务器。您能否详细介绍一下如何解决此问题？你是如何发现“有罪”的过程的？