G1垃圾回收 案例 实战

翻译以下这个视频讲述的案例：https://youtu.be/Gee7QfoY8ys

这是一个在线下棋应用
20k requests/s - 使用的Jetty server
1 server， 64 GiB RAM, 2x16 cores
Application Rate: 0.5-1.2 GiB/s
从CMS迁移到G1

问题1：MetaSpace

使用了13.72秒做Full GC
简单的修复办法，是修改MetapaceSize，但是不知道需要多大的MetaSpace
那就尝试，从大的开始尝试，比如250M，然后监控

问题2：怎么设置我们期望的暂停时间？

先试一下250ms
然后统计一下

发现，50%在250ms内完成，90%在300ms内完成，以此类推。。

问题3：Mixed GC

G1想要达到我们期望的暂停时间
不仅要考虑young regions，还要考虑old regions
在这个场景下，G1大大地减小了young generation的占比
eden region从12.4G 变成了 0.6G，Young GC变得更加频繁了（吞吐量减小了）
MMU下降（Minimum Mutator Utilization，用来衡量有多少时间Application实际在运行）

画一个事件图
一开始GC发生的频率比较低，突然GC频率变高了
分析：
一开始只是在做Young GC(低频)，过了一会，并行标记好了，G1决定来一波mixed GC，然后大幅减小eden generation的比例到0.6G，然后频繁地进行Young GC（高频），再然后Mixed GC结束了，eden generation比例变大，频率又变低了

像上面说的，对应的eden size经历了骤降再变大的过程

100%代表在时间窗口内只有Application 在run
40%代表Application run的时间少了

从这个可以看出，尽管整体来看G1表现不错
但是具体到MixedGC的时候
可能是
200ms GC + 1ms ApplicationRun
也就是说Application tried to run但是GC always interrupting

结论

G1就是未来
很有可能你啥也不用干，it just works
比起CMS更容易调参（可能只用设置一个期望的最大暂停时间😂）
仍然需要StopTheWorld
始终要用最新的JDK，因为人家天天都在优化呢😂