使用哪些工具以及如何查找Glassfish中泄漏的文件描述符?

3
我们每周都会将新代码发布到生产环境中,而Glassfish没有出现任何问题。但是这个周末我们不得不在托管提供商那里移动机架。虽然没有进行任何代码更改(只是关机、移动、重新安装和开机),但我们使用了一个新的网络基础设施,突然间我们的文件描述符像漏斗一样泄漏。所以我猜测,由于网络变化,可能会尝试建立某种连接,但现在失败了。
我正在RHEL4上运行嵌入式IMQ实例的Glassfish v2ur2-b04/AS9.1_02。搬迁后,我开始看到:
[#|2010-04-25T05:34:02.783+0000|SEVERE|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=33;_ThreadName=SelectorThread-?4848;_RequestID=c4de6f6d-c1d6-416d-ac6e-49750b1a36ff;|WEB0756: Caught exception during HTTP processing.
java.io.IOException: Too many open files
at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
...
[#|2010-04-25T05:34:03.327+0000|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err|_ThreadID=34;_ThreadName=Timer-1;_RequestID=d27e1b94-d359-4d90-a6e3-c7ec49a0f383;|java.lang.NullPointerException at
com.sun.jbi.management.system.AutoAdminTask.pollAutoDirectory(AutoAdminTask.java:1031)
使用lsof检查文件描述符的数量,我看到有很多条目看起来像:
java 18510 root 8556u sock 0,4 1555182 can't identify protocol
java 18510 root 8557u sock 0,4 1555320 can't identify protocol
java 18510 root 8558u sock 0,4 1555736 can't identify protocol
java 18510 root 8559u sock 0,4 1555883 can't identify protocol
如果我每分钟计算一次打开的文件描述符数,我会看到它每分钟增加12个。我不知道这些套接字是什么。
我已经卸载了我的应用程序,所以只有一个普通的Glassfish实例运行,但我仍然看到它每分钟泄漏12个文件描述符。因此,我认为这个泄漏存在于Glassfish或潜在的IMQ中。
我应该采取什么方法来跟踪这些未知协议的套接字?我可以使用哪些工具(或传递给lsof的标志)来获取更多关于查找位置的信息?
谢谢,
chuck

已经过去了将近一个月,仍然没有答案。你解决了这个问题吗? - Christopher Parker
1个回答

0
我找到了这个解决方案;
假设GlassFish以用户“glassfish”运行,请将以下行添加到/etc/security/limits.conf中,以增加Glassfish运行的用户的最大打开文件数:
glassfish soft nofile 32768 glassfish hard nofile 65536

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接