内存泄漏——如何发现Linux中哪个进程泄漏了文件句柄

Question

问题事件:

我们的生产系统开始拒绝服务，并出现错误消息"Too many open files in system"。大多数服务都受到影响，包括无法启动新的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

<>之前命令pid user fd type设备大小/off节点名称init 1 root cwd DIR 8,6 4096 2/init 1 root rtd DIR 8,6 4096 2/init 1 root txt REG 8,6 124704 7979050/sbin/initinit 1 root mem REG 8,6 42580 5357606/lib/i386-linux-gnu/libnss_files-2.13.soinit 1 root mem REG 8,6 243400 5357572/lib/i386-linux-gnu/libdbus-1.so.3.5.4…一个非常正常的列表，绝对不是200K文件，更像是200个。之前

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内核中的文件句柄?"one_answers"我在哪里发布这个问题?"第一个答案是有帮助的，但我愿意接受一个更好的答案。

Answer 1

可能根本原因是NFSv4实现中的错误:https://stackoverflow.com/a/5205459/280758

症状相似