9

我正在运行 Linux 2.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 报告分配比 file-max 更多的文件描述符的尝试，查找“VFS：达到文件最大限制”。

我的第一个阅读是内核基本上有一个内置的文件描述符泄漏，但我觉得这很难相信。这意味着任何处于活动状态的系统都需要每隔一段时间重新启动一次以释放文件描述符。正如我所说，我不敢相信这是真的，因为对我来说，让 Linux 系统一次运行数月（甚至数年）是很正常的。另一方面，我也不敢相信我几乎空闲的系统正在打开超过一百万个文件。

有没有人有任何想法，无论是修复还是进一步诊断？当然，我可以只重新启动系统，但我不希望这成为每隔几周重复出现的问题。作为权宜之计，我退出了 Firefox，尽管我只打开了一个窗口，但它占用了近 2000 行 lsof 输出（！），现在我可以再次运行“ls”，但我怀疑这会解决问题很久了。（编辑：哎呀，说得太早了。当我完成输入这个问题时，症状已经/回来了）

提前感谢您的帮助。

4

1 回答 1

10

我不想让一个问题悬而未决，所以给任何发现这个问题的人做一个总结。

我最终将问题重新发布在 serverfault 上（这篇文章）

实际上，他们无法提出任何建议，但我进行了更多调查，最终发现这是 NFSv4 的真正错误，特别是服务器端锁定代码。我有一个 NFS 客户端，它每 5 秒运行一次监控脚本，使用 rrdtool 将一些数据记录到 NFS 挂载的文件中。每次运行时，它都会锁定文件以进行写入，并且服务器分配（但错误地从未释放）一个打开的文件描述符。该脚本（加上另一个运行频率较低的脚本）导致每小时消耗大约 900 个打开的文件，两个月后，它达到了极限。

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

我相信您可以想到其他可能的解决方案。

感谢您的尝试。

于 2011-03-05T17:26:57.073 回答