使用哪些工具以及如何查找从 Glassfish 泄漏的文件描述符?
我们每周都会向生产环境发布新代码,Glassfish 没有遇到任何问题。这个周末我们不得不在我们的托管提供商处移动机架。没有任何代码更改(它们只是关闭、移动、重新机架并打开),但我们使用新的网络基础设施,突然我们像筛子一样泄漏文件描述符。所以我猜测正在尝试建立某种连接,但由于网络更改而失败。
我在带有嵌入式 IMQ 实例的 RHEL4 上运行 Glassfish v2ur2-b04/AS9.1_02。搬家后我开始看到:
[#|2010-04-25T05:34:02.783+0000|严重|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=33;_ThreadName=SelectorThread-?4848;_RequestID=c4de6f6d -c1d6-416d-ac6e-49750b1a36ff;|WEB0756:在 HTTP 处理期间捕获异常。
java.io.IOException:打开的文件太多
在 sun.nio.ch.ServerSocketChannelImpl.accept0(本机方法)
...
[#|2010-04-25T05:34:03.327+0000|警告|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 无法识别协议
java 18510 root 8557u sock 0,4 1555320 无法识别协议
java 18510 root 8558u sock 0,4 1555736 无法识别协议
java 18510 root 8559u sock 0,4 1555883 无法识别协议
如果我每分钟计算打开文件描述符的数量,我会发现它每分钟增长 12 个。我不知道这些插座是什么。
我已经取消部署了我的应用程序,因此只有一个普通的 Glassfish 实例在运行,但我仍然看到它每分钟泄漏 12 个文件描述符。所以我认为这次泄漏是在 Glassfish 或可能是 IMQ 中。
我应该采取什么方法来追踪这些未知协议的套接字?我可以使用哪些工具(或者可以传递给 lsof 的标志)来获取有关在哪里查找的更多信息?
谢谢,
查克
We release new code to production every week and Glassfish hasn't had any problems. This weekend we had to move racks at our hosting provider. There were not any code changes (they just powered off, moved, re-racked and powered on) but we're on a new network infrastructure and suddenly we're leaking file descriptors like a sieve. So I'm guessing there is some sort of connection attempting to be made which now fails due to a network change.
I'm running Glassfish v2ur2-b04/AS9.1_02 on RHEL4 with an embedded IMQ instance. After the move I started seeing:
[#|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)
Using lsof I check the number of file descriptors and I see quite a few entries which look like:
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
If I do a count of open file descriptors every minute I see it growing by 12 every minute. I have no idea what these sockets are.
I've undeployed my application so there is only a plain Glassfish instance running and I still see it leaking 12 file descriptors a minute. So I think this leak is in Glassfish or potentially IMQ.
What approach should I take to tracking down these sockets of unknown protocol? What tools can I use (or flags can I pass to lsof) to get more information about where to look?
thanks,
chuck
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我找到了这个解决方案;
I found this solution;