我有一个部署在 Tomcat 6 服务器上的 Grails 应用程序。该应用程序运行良好一段时间（一两天），但随着时间的推移，慢慢地消耗越来越多的内存，直到它停止运行，然后超过最大值。一旦我重新启动容器，一切都很好。我一直在使用 grails JavaMelody 插件以及应用程序信息插件来验证这一点，但我需要帮助来确定我应该寻找什么。
这听起来像是应用程序泄漏，但据我所知，无法访问任何非托管资源。另外，Hibernate 缓存似乎也受到了检查。看起来如果我运行垃圾收集器，我会收回相当多的内存，但我不知道如何可持续地做到这一点。
那么：
- 我如何使用这些（或其他）监控工具来找出问题所在？
- 还有其他建议可以帮助我吗？
非常感谢。
编辑
我正在使用 Grails 1.3.7 并且我正在使用 Quartz 插件。
I have a Grails application that is deployed on a Tomcat 6 server. The application runs fine for a while ( a day or two), but slowly eats up more and more memory over time until it grinds to a halt and then surpasses the maximum value. Once I restart the container, everything is fine. I have been verifying this with the grails JavaMelody plugin as well as the Application Info plugin, but I need help in determining what I should be looking for.
It sounds like an application leak, but to my knowledge there is no access to any unmanaged resources. Also, the Hibernate cache seems to be in check. It looks like if I run the garbage collector I get a decent chunk of memory back, but I don't know how to do this sustainably.
So:
- How can I use these (or other) monitoring tools to figure out where the problem is?
- Is there any other advice that could help me?
Thanks so much.
EDIT
I am using Grails 1.3.7 and I am using the Quartz plugin.
发布评论
评论（2）
您可以在运行时使用 Oracle JDK 中的 VisualVM 应用程序附加到 Tomcat 实例（如果已使用 Oracle JVM）以检查发生的情况。内存分析器可以告诉您很多信息并为您指明正确的方向。您很可能会寻找增长的对象或分配越来越多的对象类型。
如果您需要的内容超出了免费的 VisualVM 应用程序所能提供的范围，那么商业分析器可能会很有用。
You can use the VisualVM application in the Oracle JDK to attach to the Tomcat instance while running (if using Oracle JVM already) to inspect what goes on. The memory profiler can tell you quite a bit and point you in the right direction. You most likely look for either objects that grow or types of objects that get allocated more and more.
If you need more than the free VisualVM application can tell you, a commercial profiler may be useful.
根据您对 Quartz 的使用情况，它可能与 Quartz 插件已知内存泄漏，具有持久性和线程本地性。您可能需要仔细检查，看看这是否适用于您的情况。
Depending on your usage of Quartz it may be directly related to a know memory leak with the Quartz plugin with persistence and thread-local. You may want to double check and see if this applies to your situation.