java – 全GC变得非常频繁

前端之家收集整理的这篇文章主要介绍了java – 全GC变得非常频繁前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有一个 Java webapp在一个tomcat实例上运行.在高峰时段,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"

经过几天的正常运行时间,全面的GC开始更频繁地出现,这对于应用程序的可用性来说是一个严重的问题. tomcat重启后,问题消失了,当然在5到10或30天后返回(不一致).

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

它在重新启动之前显示一个日志,在6.6天的正常运行时间,应用程序遭受痛苦,因为Full GC需要2.5秒,每6秒钟发生一次.

然后,它显示刚刚重启之后的日志,其中Full GC仅在5-10分钟内发生.

我有两个转储使用jmap -dump:format = b,file = dump.hprof PID,当完整的GC发生时(我不知道我是否完全正确的时候完全GC发生或2个全GC之间),并在http://www.eclipse.org/mat/开张,但没有任何有用的泄漏嫌疑犯:

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

注意我从来没有得到一个OutOfMemoryError.

关于我应该在哪里看的任何想法?

解决方法

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

这意味着小的垃圾收集会更频繁地发生,并导致一些年轻物体被移动到终身一代意味着更大的垃圾收集.

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

更多信息可以找到here.

猜你在找的Java相关文章