koj*_*lin 32 java garbage-collection weak-references g1gc
我的服务器在CentOS 6.7上使用1.8.0_92,GC参数是'-Xms16g -Xmx16g -XX:+ UseG1GC'.所以默认的InitiatingHeapOccupancyPercent是45,G1HeapWastePercent是5,而G1MixedGCLiveThresholdPercent是85.我的服务器的混合GC从7.2GB开始,但它越来越少,最后老一代保持大于7.2GB,所以它总是尝试做并发标记.最后所有堆都耗尽并且发生了完整的GC.完全GC后,使用的旧版本低于500MB.
我很好奇为什么我的混合GC不能收集更多,看起来像实时数据不是那么多......
我曾尝试打印g1相关信息,并发现许多消息如下,看起来我的旧版包含很多实时数据,但为什么完整的GC可以收集这么多......
G1Ergonomics (Mixed GCs) do not continue mixed GCs, reason: reclaimable percentage not over threshold, candidate old regions: 190 regions, reclaimable: 856223240 bytes (4.98 %), threshold: 5.00 %
Run Code Online (Sandbox Code Playgroud)
以下日志是将InitiatingHeapOccupancyPercent修改为15(启动并发标记为2.4GB)以加快速度的结果.
### PHASE Post-Marking
......
### SUMMARY capacity: 16384.00 MB used: 2918.42 MB / 17.81 % prev-live: 2407.92 MB / 14.70 % next-live: 2395.00 MB / 14.62 % remset: 56.66 MB code-roots: 0.91 MB
### PHASE Post-Sorting
....
### SUMMARY capacity: 1624.00 MB used: 1624.00 MB / 100.00 % prev-live: 1123.70 MB / 69.19 % next-live: 0.00 MB / 0.00 % remset: 35.90 MB code-roots: 0.89 MB
Run Code Online (Sandbox Code Playgroud)
编辑:
我尝试在混合GC后触发完整的GC,它仍然可以减少到4xx MB,所以看起来我的旧版有更多的数据可以收集.
在完全gc之前,混合的gc日志是
32654.979: [G1Ergonomics (Mixed GCs) start mixed GCs, reason: candidate old regions available, candidate old regions: 457 regions, reclaimable: 2956666176 bytes (17.21 %), threshold: 5.00 %], 0.1106810 secs]
....
[Eden: 6680.0M(6680.0M)->0.0B(536.0M) Survivors: 344.0M->280.0M Heap: 14.0G(16.0G)->7606.6M(16.0G)]
[Times: user=2.31 sys=0.01, real=0.11 secs]
...
[GC pause (G1 Evacuation Pause) (mixed)
...
32656.876: [G1Ergonomics (CSet Construction) finish adding old regions to CSet, reason: old CSet region num reached max, old: 205 regions, max: 205 regions]
32656.876: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 67 regions, survivors: 35 regions, old: 205 regions, predicted pause time: 173.84 ms, target pause time: 200.00 ms]
32656.992: [G1Ergonomics (Mixed GCs) continue mixed GCs, reason: candidate old regions available, candidate old regions: 252 regions, reclaimable: 1321193600 bytes (7.69 %), threshold: 5.00 %]
[Eden: 536.0M(536.0M)->0.0B(720.0M) Survivors: 280.0M->96.0M Heap: 8142.6M(16.0G)->6029.9M(16.0G)]
[Times: user=2.49 sys=0.01, real=0.12 secs]
...
[GC pause (G1 Evacuation Pause) (mixed)
...
32659.727: [G1Ergonomics (CSet Construction) finish adding old regions to CSet, reason: reclaimable percentage not over threshold, old: 66 regions, max: 205 regions, reclaimable: 857822432 bytes (4.99 %), threshold: 5.00 %]
32659.727: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 90 regions, survivors: 12 regions, old: 66 regions, predicted pause time: 120.51 ms, target pause time: 200.00 ms]
32659.785: [G1Ergonomics (Mixed GCs) do not continue mixed GCs, reason: reclaimable percentage not over threshold, candidate old regions: 186 regions, reclaimable: 857822432 bytes (4.99 %), threshold: 5.00 %]
[Eden: 720.0M(720.0M)->0.0B(9064.0M) Survivors: 96.0M->64.0M Heap: 6749.9M(16.0G)->5572.0M(16.0G)]
[Times: user=1.20 sys=0.00, real=0.06 secs]
Run Code Online (Sandbox Code Playgroud)
编辑: 2016/12/11
我从另一台机器上卸下了堆-Xmx4G.
我使用莴苣作为我的redis客户端,它使用LatencyUtils进行跟踪.它使LatencyStats(其中包含一些long[]具有近3000个元素的实例)每10分钟被弱化一次(默认情况下,发布后的重置延迟为真,https://github.com/mp911de/lettuce/wiki/Command-Latency-Metrics).所以它会在很长一段时间后对LatencyStats进行大量的弱引用.
目前我不需要从生菜跟踪,所以只需禁用它,它就不再有完整的GC了.但不确定为什么混合gc不会清除它们.
小智 1
好吧,你没有提到你设置的所有参数,但是
你可以尝试设置
-XX:+ScavengeBeforeFullGC
Run Code Online (Sandbox Code Playgroud)
你还应该考虑你的Object生命周期。您的应用程序的生命周期有多长Object以及应用程序的大小是多少Object。
想一想并看看以下论点
-XX:NewRatio=n old/new ration (default 2)
-XX:SurvivorRatio=n eden/survivor ratio (default 8)
-XX:MaxTenuringThreshold=n number of times, objects are moved from survivor one to survivor two and vice versa before objects are moved to old-gen (default 15)
Run Code Online (Sandbox Code Playgroud)
默认值 Xms 和 Xmx 设置为 32gb -> 旧代 = 16gb 和新代 16gb -> eden 14gb -> 幸存者 2gb (有两个,每个大小为 1gb)
eden 包含Object由 实例化的所有 s new Object。
一个幸存者(to-survivor)总是空的。其他的(from-survivor)包含Object在一次小GC中幸存下来的s
来自 eden 和 from-survivor 的幸存Objects 在次要GC时进入 to-survivor
如果此“默认配置”超过 1GB 的标准大小,Object则进入旧代
如果不超过15次minor gc(-XX:MaxTenuringThreshold默认值),Object则进入old-gen
通过调整这些值,请始终记住,旧代必须与新代一样大或更大,因为GC可能导致整个新代进入旧代
编辑
你的第一张“旧一代:二手”图片的时间线会很有帮助
请记住,在老一代不超过之前,不需要执行完整的GC - 完整的GC会导致整个“世界”停止一段时间
在这种特殊情况下,我想说你可以
-Xms至-Xmx8GB-XX:SurvivorRatio为 2-XX:MaxTenuringThreshold50你会得到一个旧的和一个新的一代,每个大小 4GB,
伊甸园大小为2GB,
两名幸存者,每人大小 1GB,
Object在进入老一代之前,大约有 50 个次要 GC
| 归档时间: |
|
| 查看次数: |
1367 次 |
| 最近记录: |