Finalizer 内存泄漏或服务器过载
我们有一个正在生产中的 JBoss JDK 7 应用程序服务器，随着时间的推移，速度会变慢，连接数量会增加（随着处理时间的增加），最终需要重新启动服务器并再次开始循环。
在 GC 日志上使用 GCViewer 如下所示：
在堆转储上使用 Eclipse MAT，Leak Suspects 显示以下内容：
<一个href="https://i.sstatic.net/OLcLQ.png" rel="nofollow noreferrer">
主要的泄漏嫌疑是：java.lang.ref.Finalizer 使用37.57% (501.7 MB)。
如果我点击详细信息 -> 按类列出所有累积对象，然后按类名MessageContext进行过滤。
我可以右键单击 org.apache.axis.MessageContext 并选择计算精确保留大小。
这显示保留堆为419.81 MB。
这似乎是 501.7 MB 的大部分。
org.apache.axis.MessageContext 类包含在我们的应用程序使用的 axis-1.4.jar 中。
查看Java 基础知识 -> 终结器概述
Finalizer 线程似乎没有被阻塞
所以我的问题是：
我的计算步骤是org.apache.axis.MessageContext 对象的终结器持有的大部分内存正确吗？
终结器是否包含许多 org.apache.axis.MessageContext 对象，我应该进一步调查？该应用程序是一个处理 XML 消息的规则引擎，将它们从一个线程发送到另一个线程，因此这可能就是它在重负载下的样子。在单独的堆转储中，主要泄漏嫌疑人 java.lang.ref.Finalizer 为 922.68 MB (56.17%)，在这种情况下为 org. apache.axis.MessageContext 对象为 771 MB。
我可以使用 MAT 或其他哪些其他步骤来缩小此问题的范围？有什么方法可以确定应用程序过载、有太多长时间运行的请求，而不是存在固有的内存泄漏？有其他服务器运行相同的应用程序，但没有表现出此行为。
对上述问题的任何帮助将不胜感激。
We have a JBoss JDK 7 application server in production, that is slowing down over time, the number of connections increasing (as processing time increases) eventually the server needs to be restarted and the cycle starts again.
Using GCViewer on the GC log looks like this:
Using Eclipse MAT on a heap dump, Leak Suspects shows this:
The main leak suspect is: java.lang.ref.Finalizer using 37.57% (501.7 MB).
If I then click on Details -> All Accumulated Objects by Class and then filter by the class name MessageContext.
I can the right click on org.apache.axis.MessageContext and select Calculate Precise Retained Size.
This shows a Retained Heap of 419.81 MB.
This would appear to be the majority of the 501.7 MB.
The org.apache.axis.MessageContext class is contained in the axis-1.4.jar used by our application.
Looking at the Java Basics -> Finalizer Overview
The Finalizer thread does not seem to be blocked
So my questions are:
Are my steps to calculate that the majority of memory held by Finalizers for org.apache.axis.MessageContext objects correct?
Is the Finalizer holding many org.apache.axis.MessageContext objects something I should investigate further? The application is a rule engine processing XML messages, sending them from one thread to another so this is possibly how it would look under heavy load. In a separate heap dump the primary Leak Suspect java.lang.ref.Finalizer was 922.68 MB (56.17%), in that case the Retained heap for org.apache.axis.MessageContext objects was 771 MB.
What other steps using MAT or other can I use to narrow down this issue? Is there any way to determine that the application is overloaded, has too many long running requests, rather than there is an inherent memory leak? There are other servers running the same application that are not exhibiting this behaviour.
Any help on the above questions would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论