完整的GC变得非常频繁

che*_*vim 13 java performance garbage-collection jvm

我在一个tomcat实例上运行了一个Java webapp.在高峰时段,webapp每秒大约30页,通常大约15页.

我的环境是:

O/S: SUSE Linux Enterprise Server 10 (x86_64)
RAM: 16GB

server: Tomcat 6.0.20
JVM: Java HotSpot(TM) 64-Bit Server VM 1.6.0_14
JVM options:
CATALINA_OPTS="-Xms512m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m
               -XX:+UseParallelGC
               -Djava.awt.headless=true
               -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps"
JAVA_OPTS="-server"
Run Code Online (Sandbox Code Playgroud)

经过几天的正常运行后,Full GC开始更频繁地发生,并且它成为应用程序可用性的严重问题.在tomcat重新启动之后,问题就会消失,但当然会在5到10天或30天之后返回(不一致).

重启之前和之后的完整GC日志位于http://pastebin.com/raw.php?i=4NtkNXmi

它显示重启之前的日志,在6.6天的正常运行时间,因为完整的GC需要2.5秒,并且每隔约6秒发生一次.

然后它会在重新启动后显示一个日志,其中Full GC仅每5-10分钟发生一次.

jmap -dump:format=b,file=dump.hprof PID当Full GCs出现时,我有两个转储(我不确定在完整GC发生时是否完全正确,或者在两个完整GC之间),并在http://www.eclipse.org中打开它们/ mat /但在泄漏嫌疑人中没有得到任何有用的东西:

  • 60MB:"org.hibernate.impl.SessionFactoryImpl"的1个实例(我使用带有ehcache的hibernate)
  • 80MB:1,024个"org.apache.tomcat.util.threads.ThreadWithAttributes"实例(这些可能是tomcat的1024个工作者)
  • 45MB:37个"net.sf.ehcache.store.compound.impl.MemoryOnlyStore"实例(这些应该是我在ehcache中的~37个缓存区域)

请注意,我从未得到过OutOfMemoryError.

关于我下一步应该去哪看的任何想法?

Jim*_*Jim 7

当我们遇到这个问题时,我们最终将其追溯到年轻一代太小.虽然我们已经给了很多公羊,但年轻一代并没有得到公平的分享.

这意味着小垃圾收集会更频繁地发生,并导致一些年轻的对象被移动到tenured generation,这意味着更大的垃圾收集.

尝试使用-XX:NewRatio相当低的值(比如2或3),看看这是否有帮助.

更多信息可以在这里找到.


che*_*vim 4

我已经从 切换-Xmx1024m-Xmx2048m,问题就消失了。我现在有 100 天的正常运行时间。