如何帮助java tomcat进程重新获得使用的内存？答案

【问题标题】：How to help java tomcat processes to regain used memory?如何帮助java tomcat进程重新获得使用的内存？
【发布时间】：2009-04-02 23:27:07
【问题描述】：

我们正在运行一个使用 Java 64 位 5 gigs 的 -Xmx 最大堆大小的 Web 应用程序。我们无法控制 java 代码。我们只能调整配置参数。我们面临的情况是，Java 进程在启动时占用了分配的全部堆后，它开始对网站请求的响应非常缓慢。我的猜测是等待 GC 收集未使用的内存对象。

下图将向您展示 linux 中的 top 图像，显示进程的危急情况。

top image of java process http://cp.images.s3.amazonaws.com/ForumImages/java-gc-issue.jpg

有什么办法可以帮助java重新获得分配空间内已使用的内存。

编辑 1：我使用下面的一些答案来回答我的问题。因为我的问题太难回答了，结果变成了讨论。我将发布我如何能够监控 GC 周期，并且我会以更多的票数选择答案。我通过真正的 vnc 查看器使用了 jconsole，以便能够从我的 windows 机器挂钩到运行 tomcat 的 linux 机器。

我使用这个参数来启动java进程：

-Djava.awt.headless=true -server -Xms512m -Xmx5120m -Dbuild.compiler.emacs=true -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=4999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

这是我得到的输出类型，从 jconsole 到 vnc 查看器。 GC Sample Image http://cp.images.s3.amazonaws.com/ForumImages/Sample_GC_Image.jpg

【问题讨论】：

这与编程无关。

标签： java memory tomcat memory-management

【解决方案1】：

我建议你不要猜测。获取一些数据以确切了解发生了什么。您可以使用visual gc 来查看发生了什么。

如果是烫发空间被填满，你就无能为力了。

哪个JVM？如果它是 5 或更高，那么除了最大堆大小之外，您还可以调整其他参数。查看http://blog.springsource.com/2008/10/14/optimising-and-tuning-apache-tomcat-part-2/

【讨论】：

【解决方案2】：

如果您的应用程序越来越慢，这听起来像是内存泄漏。 GC 总是会在需要时立即开始清理未使用的对象。如果添加 -verbosegc，您将能够看到执行 GC 的频率以及 GC 后有多少内存可用。如果堆的使用率超过 80%，则必须增加最大内存或修复程序以使其不使用太多。

你能做一个numactl --hardware 吗？我建议你不要使用超过 80% 的内存库，否则你的 GC 时间会急剧增加。

【讨论】：

“一个内存库的使用率不超过 80%”，听起来很有趣。您对此声明有参考或基准吗？
好问题。这主要是来自 RedHat 专家的观察和技术轶事。我发现内存架构对延迟有很大影响，但我还没有测量吞吐量。

【解决方案3】：

听起来您需要了解堆栈使用情况的详细信息。为此，我推荐 JMAP (http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jmap.html)，您可以在进程 ID (PID) 上运行它以查看正在使用内存的内容。在应用程序运行时多次拍摄 JMAP 快照，看看哪些类没有释放堆栈。

干杯，

-理查德

【讨论】：

【解决方案4】：

尝试使用-verbose:gc -Xloggc:/path/to/where/you/want/gc.log 参数运行应用程序，并研究生成的gc.log；它应该告诉您在垃圾收集上花费了多少时间。或者，正如上面 Duffymo 建议的那样，使用 visualGC 为您提供相同的数据。

确保您使用的是合适的收集器 - 假设您使用的是 java 5，您可能需要并行或低暂停 (CMS) 收集器。

阅读Sun's GC tuning document 以了解您还可以调整什么。有时我发现非常大的堆会适得其反（假设应用程序实际上并不需要所有空间）；更频繁、更小的收集有时最终会比偶尔的大规模收集带来更少的破坏性。

【讨论】：