linux – 为什么(或如何)root使用的打开文件描述符的数量超过ulimit -n？

我们的服务器最近耗尽了文件描述符,关于这一点,我有一些问题. ulimit -n应该给我最大数量的打开文件描述符.这个数字是1024.我通过运行lsof -u root | wc -l检查了打开文件描述符的数量,得到了2500 fds.这远远超过1024,所以我猜这意味着每个进程的数字是1024,而不是每个用户,就像我一样.好吧,我跑了lsof -p $PidOfGlassfish | wc -l并得到1300.这是我没有得到的部分.如果ulimit -n不是每个用户或每个进程的最大进程数,那么它有什么用呢？它不适用于root用户吗？如果是这样,我怎么能得到关于用完文件描述符的错误消息？

编辑：我能从ulimit -n中理解的唯一方法是它是否应用了打开文件的数量(如bash手册中所述)而不是文件句柄的数量(不同的进程可以打开同一个文件).如果是这种情况,那么只需列出打开文件的数量(点击’/’,从而排除内存映射文件)是不够的：

lsof -u root |grep /|sort  -k9  |wc -l #prints '1738'

要实际查看打开文件的数量,我需要在名称列上过滤仅打印唯一条目.因此以下可能更正确：

lsof -u root |grep /|sort  -k9 -u |wc -l #prints '604'

上面的命令期望从lsof输出以下格式：

java      32008 root  mem       REG                8,2 11942368      72721 /usr/lib64/locale/locale-archive
vmtoolsd   4764 root  mem       REG                8,2    18624     106432 /usr/lib64/open-vm-tools/plugins/vmsvc/libguestInfo.so

这至少给了我小于1024的数字(ulimit -n报告的数字),所以这似乎是朝着正确方向迈出的一步. “不幸的是”我没有遇到任何用完文件描述符的问题,所以我很难验证这一点.

解决方法

我在Linux版本2.6.18-164.el5中测试了这个 – Red Hat 4.1.2-46.
我可以看到每个进程都应用了ulimit.

该参数在用户级别设置,但适用于每个进程.

例如：1024是限制.
启动多个进程,并使用每个进程打开文件

ls -l /proc/--$pid--/fd/ | wc -l

当多个进程打开的文件总数超过1024时,没有错误.我还验证了结合不同进程的结果和计算唯一文件的唯一文件计数.只有当每个进程的计数超过1024时,才会出现错误.(java.net.socketException：进程日志中打开的文件太多)