老Gen堆已经满了,Eden和Survivor很低,几乎是空的

Question

最近生产环境变得非常缓慢.该过程的CPU占了200%.它继续工作.重新启动服务后,它再次正常运行.我有几个症状:Par幸存者空间堆很长时间都是空的,垃圾收集占用了大约20%的cpu时间.

JVM选项:

X:+CMSParallelRemarkEnabled, -XX:+HeapDumpOnOutOfMemoryError, -XX:+UseConcMarkSweepGC, -                XX:+UseParNewGC, -XX:HeapDumpPath=heapdump.hprof, -XX:MaxNewSize=700m, -XX:MaxPermSize=786m, -XX:NewSize=700m, -XX:ParallelGCThreads=8, -XX:SurvivorRatio=25, -Xms2048m, -Xmx2048m

     Arch   amd64
     Dispatcher Apache Tomcat
     Dispatcher Version 7.0.27
     Framework  java
     Heap initial (MB)  2048.0
     Heap max (MB)  2022.125
     Java version   1.6.0_35
    Log path    /opt/newrelic/logs/newrelic_agent.log
    OS  Linux
    Processors  8
    System Memory   8177.964, 8178.0

附加图片中的更多信息当非堆上出现问题时,使用的代码缓存和使用的cms perm gen降至一半.

我从新手中获取了信息.

问题是为什么服务器开始工作这么慢.

有时服务器完全停止,但我们发现PDFBox存在问题,当上传一些pdf并包含一些字体时,它会崩溃JVM.

更多信息:我观察到Old gen每天都在填满.现在我每天重启服务器.重新启动后,这一切都很好,花花公子,但旧的一直在填补,直到第二天,服务器减速直到需要重新启动.

Answer 1

默认情况下,如果OldGen为70%,CMS将开始同时收集.如果它不能释放低于此边界的内存,它将永久并发运行,这将显着减慢操作.如果OldSpace接近完全使用OldGen,它将会出现恐慌并回落到停止世界的GC暂停,这可能会很长(例如20秒).您可能需要在OldGen中有更多的空间(确保您的应用程序不会泄漏内存!).此外,您可以使用降低阈值来启动并发收集(默认为70%)

-XX:+ UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction = 50

这将触发以50%占用率开始的并发收集,并增加CMS及时完成GC的机会.这只会在您的分配率过高的情况下有所帮助,从您的图表看起来不够 - headrooom/memleak +太高XX:CMSInitiatingOccupancyFraction.提供至少500MB到1 GB的OldGen空间