VFS:达到文件最大限制1231582

Question

我正在运行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&file-nr:

内核动态分配文件句柄,但是它还没有再次释放它们.

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

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

使用printk报告尝试分配比file-max更多的文件描述符,查找"VFS:达到文件最大限制".

我第一次看到这个内核基本上有一个内置的文件描述符泄漏,但我发现很难相信.这意味着需要每隔一段时间重新启动任何处于活动状态的系统以释放文件描述符.正如我所说,我不敢相信这是真的,因为让Linux系统一次保持数月(甚至数年)是正常的.另一方面,我也无法相信我的近乎闲置的系统正在打开超过一百万个文件.

有没有人有任何想法,无论是修复还是进一步诊断？当然,我可以重新启动系统,但我不想每隔几周就会出现这种问题.作为权宜之计,我已经退出了Firefox,它占了近2000行lsof输出(!),即使我只有一个窗口打开,现在我可以再次运行'ls',但我怀疑这会修复问题很久了.(编辑:哎呀,说得太快.当我输入这个问题的时候,症状是/回来了)

在此先感谢您的帮助.

Answer 1

我不想打开一个问题,所以对于发现这个问题的人来说,这是一个总结.

我最后在serverfault上重新发布了这个问题(本文)

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

有几种解决方案是可行的:1)使用NFSv3代替.2)停止运行监视脚本.3)将监控结果存储在本地而不是NFS上.4)等待补丁到NFSv4修复此问题(Bruce Fields实际上给了我一个补丁试试,但我还没有时间)

我相信你能想到其他可能的解决方案.

谢谢你的尝试.