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

发布于 2024-08-30 09:29:49 字数 1420 浏览 7 评论 0原文

我们每周都会向生产环境发布新代码,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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

Oo萌小芽oO 2024-09-06 09:29:49

我找到了这个解决方案;

假设 GlassFish 以用户身份运行
“玻璃鱼”

将以下行添加到
/etc/security/limits.conf 增加
最大打开文件数
Glassfish 运行的用户:

glassfish 软 nofile 32768
glassfish硬诺菲勒65536

I found this solution;

assuming GlassFish runs as user
"glassfish"

Add the following lines to
/etc/security/limits.conf to increase
the maximum number of open files for
the user that Glassfish runs as:

glassfish soft nofile 32768
glassfish hard nofile 65536

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文