我们的服务器最近耗尽了文件描述符,关于这一点,我有一些问题. 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.
我可以看到每个进程都应用了ulimit.
该参数在用户级别设置,但适用于每个进程.
例如:1024是限制.
启动多个进程,并使用每个进程打开文件
ls -l /proc/--$pid--/fd/ | wc -l
当多个进程打开的文件总数超过1024时,没有错误.我还验证了结合不同进程的结果和计算唯一文件的唯一文件计数.只有当每个进程的计数超过1024时,才会出现错误.(java.net.SocketException:进程日志中打开的文件太多)
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。