【发布时间】：2014-03-28 14:06:10
【问题描述】：
问题事件：
我们的生产系统开始拒绝服务并显示错误消息“系统中打开的文件过多”。大多数服务都受到了影响，包括无法启动新的 ssh 会话，甚至无法从物理终端登录到虚拟控制台。幸运的是，一个根 ssh 会话是打开的，所以我们可以与系统交互（士气：保持一个根会话始终打开！）。作为副作用，一些服务（named、dbus-daemon、rsyslogd、avahi-daemon）使 CPU 饱和（100% 负载）。该系统还通过NFS 为一个非常繁忙的客户端提供一个大目录，该客户端目前正在备份50000 个小文件。重新启动各种服务和程序使其 CPU 行为正常化，但并没有解决“系统中打开的文件过多”问题。
怀疑原因
很可能，某些程序正在泄漏文件句柄。可能罪魁祸首是我的 tcl 程序，它也使 CPU 饱和（不正常）。然而，杀死它并没有帮助，但最令人不安的是，lsof 不会显示大量打开的文件。
一些证据
我们必须重新启动，所以收集到的信息就是我们所拥有的一切。
root@xeon:~# cat /proc/sys/fs/file-max
205900
root@xeon:~# lsof
这可能是问题开始的地方：
less /var/log/syslog
Mar 27 06:54:01 xeon CRON[16084]: (CRON) error (grandchild #16090 failed with exit status 1)
Mar 27 06:54:21 xeon kernel: [8848865.426732] VFS: file-max limit 205900 reached
Mar 27 06:54:29 xeon postfix/master[1435]: warning: master_wakeup_timer_event: service pickup(public/pickup): Too many open files in system
Mar 27 06:54:29 xeon kernel: [8848873.611491] VFS: file-max limit 205900 reached
Mar 27 06:54:32 xeon kernel: [8848876.293525] VFS: file-max limit 205900 reached
netstat 也没有显示出明显的异常。
ps 和 top 的手册页不表示能够显示打开文件计数。几个月后问题可能会再次出现（那是我们的正常运行时间）。
还有什么其他方法可以识别打开的文件吗？
更新
在qehgt确定了可能的原因之后，这个问题已经改变了意思。
除了 NFS v4 代码中的错误之外，我怀疑 Linux 中存在设计限制，并且可以不识别内核泄漏的文件句柄。因此，原始问题转换为： “谁负责 Linux 内核中的文件句柄？”和“我在哪里发布这个问题？”。第一个答案很有帮助，但我愿意接受更好的答案。
【问题讨论】：
-
你使用 NFS 共享吗？
-
是的，正如我在问题中所说，它被大量使用至少一个小时：
root@xeon:~# cat /etc/exports/data/shared-files 192.168.1.0/255.255.255.0(rw,insecure,no_root_squash,anonuid=1000,anongid=1000,no_subtree_check)
标签： file memory-leaks linux-kernel