java - 应用程序启动后几分钟内 GC Tenuring 阈值就会下降

Question

REST APP(仅从 MongoDB 检索数据并以 JSON 格式返回)在 GC 日志中显示，启动后几分钟内保留阈值降至 1。

据我了解，这意味着对象在第一次小型 GC 后被提升到老一代(不会进入幸存者空间)。

在我看来，这种情况可能会发生在幸存者空间不够大的情况下，但我尝试尽可能增加它，但没有帮助。

Java:

java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

JVM参数:

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:MaxPermSize=512m -Xms10g -Xmx10g -Xmn9g -XX:SurvivorRatio=1 -Xloggc:gc.log -XX:+PrintTenuringDistribution

在不增加幸存者配给和年轻空间的情况下，也会发生相同的结果。

应用的 GC(来自 JConsole VM 摘要)[编辑]:

• 旧一代的 PS MarkSweep
• 年轻一代的 PS Scavenge

GC 日志:

    27.066: [GC
Desired survivor size -1073741824 bytes, new threshold 7 (max 15)
 [PSYoungGen: 3145728K->356400K(6291456K)] 3145728K->356560K(7340032K), 0.3177926 secs] [Times: user=0.42 sys=0.05, real=0.32 secs] 
36.507: [GC
Desired survivor size -1073741824 bytes, new threshold 7 (max 15)
 [PSYoungGen: 3502128K->382760K(6291456K)] 3502288K->382928K(7340032K), 0.2196291 secs] [Times: user=0.39 sys=0.01, real=0.22 secs] 
77.584: [GC
Desired survivor size -1073741824 bytes, new threshold 7 (max 15)
 [PSYoungGen: 3528488K->148479K(6291456K)] 3528656K->148655K(7340032K), 0.0672362 secs] [Times: user=0.20 sys=0.00, real=0.07 secs] 
86.079: [GC
Desired survivor size -1073741824 bytes, new threshold 7 (max 15)
 [PSYoungGen: 3294207K->129156K(6291456K)] 3294383K->129340K(7340032K), 0.0599233 secs] [Times: user=0.25 sys=0.00, real=0.06 secs] 
92.699: [GC
Desired survivor size 472383488 bytes, new threshold 6 (max 15)
 [PSYoungGen: 3274884K->129472K(6291456K)] 3275068K->129664K(7340032K), 0.0523734 secs] [Times: user=0.20 sys=0.00, real=0.05 secs] 
101.012: [GC
Desired survivor size 459276288 bytes, new threshold 5 (max 15)
 [PSYoungGen: 3275200K->130300K(8988672K)] 3275392K->130500K(10037248K), 0.0669330 secs] [Times: user=0.22 sys=0.05, real=0.07 secs] 
125.649: [GC
Desired survivor size 454557696 bytes, new threshold 4 (max 15)
 [PSYoungGen: 8657660K->85345K(8975872K)] 8657860K->173403K(10024448K), 0.6692181 secs] [Times: user=0.25 sys=0.19, real=0.67 secs] 
148.465: [GC
Desired survivor size 462422016 bytes, new threshold 3 (max 15)
 [PSYoungGen: 8612705K->6344K(8977920K)] 8700763K->132249K(10026496K), 0.0723653 secs] [Times: user=0.06 sys=0.06, real=0.07 secs] 
178.740: [GC
Desired survivor size 462422016 bytes, new threshold 2 (max 15)
 [PSYoungGen: 8540360K->6658K(8985600K)] 8666265K->132919K(10034176K), 0.0336259 secs] [Times: user=0.00 sys=0.00, real=0.03 secs] 
213.928: [GC
Desired survivor size 457703424 bytes, new threshold 1 (max 15)
 [PSYoungGen: 8540674K->6018K(8990208K)] 8666935K->133350K(10038784K), 0.0146560 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 

任何有关解决此问题的方法的想法或有关任期阈值自动调整的文件都将受到高度赞赏。

Answer 1

经过长时间的讨论和实验，我将总结我对这个问题的想法:

您的虚拟机默认选择 ParallelGC，并且它正在尝试通过各种方式增加吞吐量。通常，收集器在这方面相当聪明，但显然还不够聪明，无法在所有情况下产生最佳结果。特别是考虑到您的堆对于 ParallelGC 来说相当大，而 ParallelGC 的设计目的并不是有效地处理此类内存卷。不幸的是，G1GC 被设计用来替换大型堆上的其他收集器，在您的 VM 版本中相当薄弱，并且不太可能产生更好的结果。

如果您在暂停或吞吐量方面没有任何实际问题，我不建议您继续使用xmx。 , xmn , xms , MaxGCPauseMillis和GCTimeRatio ，因为在 Old Gen 中拥有对象本身并不坏，只有当 Full GC 导致不满足您的需求的暂停时，它才是坏的。但是，如果考虑到所有因素，您仍然希望在任何情况下都使 GC 保持较高的保留阈值，您可以通过设置 -XX:-UseAdaptiveSizePolicy 来关闭收集器的“智能”。 。它将阻止自动调整，并允许您指定收集器不会更改的所需区域大小和阈值 ( -XX:MaxTenuringThreshold=? )。它对于学习目的也很有用，但在生产中要小心。