Question

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

据我了解，这意味着在第一次小型GC之后，对象会被提升为Old Gen（不会进入Survivor Space）。

在我看来，这种情况可能发生在幸存者空间不够大，但我试图增加它，因为我有资源，它没有帮助。

爪哇：

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 for Old Gen
PS Scavenge for Young Gen

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

经过长时间的讨论和实验后，我总结了我对这个问题的看法：

默认情况下，您的VM选择了ParallelGC，并尝试通过各种方式提高吞吐量。通常情况下，收藏家非常聪明，但显然不够聪明，无法在所有情况下产生最佳效果。特别是考虑到您的堆对于ParallelGC来说非常大，而这个并不是为了有效地处理这样的内存量而设计的。不幸的是，G1GC被设计为替换大型堆上的其他收集器，在您的VM版本中相当弱，并且不太可能产生更好的结果。

如果您对暂停或吞吐量没有任何实际问题，我建议不要超过xmx，xmn，xms，MaxGCPauseMillis和GCTimeRatio，因为Old Gen中的对象本身并不坏，只有当完整的GC导致暂停不能满足您的要求时，它才会变坏。但是，如果经过一切考虑后你仍然想让GC在任何情况下都保持高水平的门槛，那么你可以关掉收藏家的智慧＆＃39;通过设置-XX:-UseAdaptiveSizePolicy。它将阻止自动调整，并允许您指定收集器不会更改的所需区域大小和阈值（-XX:MaxTenuringThreshold=?）。它对学习目的也很有用，但在制作时要小心。

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

1 个答案: