java - 老一代堆满了，伊甸园和幸存者很矮，几乎是空的

最近生产环境变得非常缓慢。该过程的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减少一半。

我从newrelic获取了信息。

问题是为什么服务器开始如此缓慢地工作。

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

更多信息:我观察到，老一代人每天都充满了。现在，我每天重新启动服务器。重新启动后，一切都很好，但老一代人已经花光了，直到第二天，服务器速度变慢，直到需要重新启动。

最佳答案

默认情况下，如果OldGen为70％，CMS将开始并发收集。如果无法释放此边界以下的内存，它将永久并发运行，这将大大降低操作速度。如果OldSpace即将完全使用OldGen，它将惊慌失措并退回到世界停止GC暂停，这可能会很长(例如20秒)。
您可能需要在OldGen中留出更多空间(确保您的应用程序不会泄漏内存!)。此外，您可以使用以下方法降低启动并发收集的阈值(默认为70％)

-XX:+仅使用CMSInitiatingOccupancy
-XX:CMSInitiatingOccupancyFraction = 50

这会从50％的占用率开始触发并发收集，并增加CMS及时完成GC的机会。这仅在您的分配率太高的情况下才有帮助，从您的图表来看，它似乎不够大/内存泄漏+ XX:CMSInitiatingOccupancyFraction太高。至少增加500MB到1 GB的OldGen空间