[ZGC升级记录](to-space exhausted/Evacuation Failure)

1. 问题背景

服务中存在大量的全量数据的接口，需要把运营平台配置的全量数据拉取下来，存在大量的大对象(结果实现服务有100M左右)，传给垂域或者传给质量组监控。这就给GC带来了很大压力。
小爱5.0场景配置服务上线后，观测到服务很不稳定，经常99-percentile > 4s, 性能很不稳定。

解决方案和收益

2.1 解决方案

从根本上解决应该避免大量大对象的产生，这需要花费很大的人力成本去做迁移和重构
升级ZGC垃圾回收器(可以实现并发转移)，STW非常短
修改参数

让G1更早得启动混合式垃圾收集周期，通过调小-XX:InitiatingHeapOccupancyPercent=N这个参数，默认情况下该参数是45（PS：这个参数表示的是占用整个堆内存的比例），不过，这个参数也不能调得太小，否则会导致过多的并发收集周期和混合式垃圾收集，给应用早成过多的停顿。

除了考虑增加速度，还可以考虑增加每次混合式垃圾收集收集的Old分区数量，通过调整-XX:G1MixedGCCountTarget=N参数可以控制每个混合式周期中回收的Old分区数量，该参数的默认值是8

2.2 收益

我们采用方案1和2结合的方式，先升级ZGC，然后等人力空闲在将全量接口服务重构迁移到合适的模块,性能尖刺基本消失，服务接口99-percentile 耗时基本在15ms一下

3. 详细过程

经过排查，我们发现G1回收过程中，对象复制(STW)花费的事件很长(> 4s)，G1日志分析如下：

老区不够了，这个时候会把young区所有对象不管死活都转成old区对象，所以总的内存使用量会暴增。

to-space exhausted: 巨型对象过多导致的内存碎片，引起混合疏散失败
Object Copy: eden, suvivor的regions全变为0，这两个space的对象全部移到了old区, 导致占用非常长的时间
Evacuation Failure: 疏散失败也占用一定的影响

{Heap before GC invocations=2685 (full 0):garbage-first heap   total 4194304K, used 4030503K [0x00000006c0000000, 0x00000006c0204000, 0x00000007c0000000)region size 2048K, 1120 young (2293760K), 15 survivors (30720K)Metaspace       used 84996K, capacity 86085K, committed 86276K, reserved 1126400Kclass space    used 9716K, capacity 9960K, committed 10032K, reserved 1048576K
2022-02-18T10:36:14.280+0800: 756600.145: [GC pause (G1 Evacuation Pause)
(young)2022-02-18T10:36:18.332+0800: 756604.198: [SoftReference, 0 refs,
0.0000722 secs]2022-02-18T10:36:18.333+0800: 756604.198:
[WeakReference, 0 refs, 0.0000117 secs]2022-02-18T10:36:18.333+0800:
756604.198: [FinalReference, 0 refs, 0.0000081 secs]
2022-02-18T10:36:18.333+0800: 756604.198: [PhantomReference, 0 refs, 0 refs,
0.0000089 secs]2022-02-18T10:36:18.333+0800: 756604.198: [JNI Weak Reference,
0.0000499 secs] **(to-space exhausted)**, 4.2319898 secs][Parallel Time: 4047.8 ms, GC Workers: 28][GC Worker Start (ms): Min: 756600146.8, Avg: 756600147.2, Max: 756600147.6, Diff: 0.8][Ext Root Scanning (ms): Min: 0.6, Avg: 1.3, Max: 6.4, Diff: 5.8, Sum: 36.4][Update RS (ms): Min: 12.5, Avg: 15.2, Max: 17.2, Diff: 4.7, Sum: 426.0][Processed Buffers: Min: 18, Avg: 31.0, Max: 43, Diff: 25, Sum: 868][Scan RS (ms): Min: 1.5, Avg: 3.2, Max: 4.5, Diff: 3.0, Sum: 90.7][Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]**[Object Copy (ms): Min: 4013.0, Avg: 4016.0, Max: 4025.6, Diff: 12.6, Sum: 112448.8]**[Termination (ms): Min: 0.0, Avg: 11.1, Max: 13.3, Diff: 13.3, Sum: 311.1][Termination Attempts: Min: 1, Avg: 1.2, Max: 3, Diff: 2, Sum: 35][GC Worker Other (ms): Min: 0.0, Avg: 0.2, Max: 0.3, Diff: 0.3, Sum: 4.3][GC Worker Total (ms): Min: 4046.6, Avg: 4047.1, Max: 4047.6, Diff: 1.1, Sum: 113317.4][GC Worker End (ms): Min: 756604194.1, Avg: 756604194.2, Max: 756604194.4, Diff: 0.3][Code Root Fixup: 0.1 ms][Code Root Purge: 0.0 ms][Clear CT: 1.9 ms][Other: 182.2 ms]**[Evacuation Failure: 163.7 ms]**[Choose CSet: 0.0 ms][Ref Proc: 3.2 ms][Ref Enq: 0.0 ms][Redirty Cards: 5.2 ms][Humongous Register: 0.5 ms][Humongous Reclaim: 4.9 ms][Free CSet: 3.1 ms][Eden: 2210.0M(2258.0M)->0.0B(2176.0M) Survivors: 30.0M->0.0B Heap: 3936.0M(4096.0M)->1400.0M(4096.0M)]
Heap after GC invocations=2686 (full 0):garbage-first heap   total 4194304K, used 1433600K [0x00000006c0000000, 0x00000006c0204000, 0x00000007c0000000)region size 2048K, 0 young (0K), 0 survivors (0K)Metaspace       used 84996K, capacity 86085K, committed 86276K, reserved 1126400Kclass space    used 9716K, capacity 9960K, committed 10032K, reserved 1048576K
}

3.1 修改配置

sbt和scala的版本升级，sbt升级到0.13.18, scala版本升级到2.11.12
添加插件addSbtPlugin(“com.typesafe.sbt” % “sbt-native-packager” % “1.3.4”)
修改build.sbt，添加对新版packger的依赖
修改application.conf中的gc配置 -> (app.jvm.arg = ${app.jvm.medium_zgc})
修改母项目build.yaml中的部署配置

3.2 踩坑记录

sbt ,scala和JDK11兼容问题
JDK11推荐scala版本2.11.12，sbt版本0.13.18,详见https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html
部署后启动失败
stderr里面显示The java installation you have is not up to daterequires at least version 1.6+, you have version 11.0.2，部署生成的启动脚本对java版本的比较写的有问题。
需要对引入sbt stage的包sbt-native-packager做一下升级。升级版本后build.sbt会报错，因为bashScriptExtraDefines的字段在1.3.4中被移动到其它位置了，需要修改下引用。

3. 部署后，falcon上无日志

机器有zgc日志
job ‘job.zgcmonitor_service.watcherd_cluster.c3_pdl.AI-Service_owt.AI_cop.xiaomi’ RUNNING, work 355715 (2022-01-14 16:50:17) 机器上有这个监控进程
若没有，需要联系sre给机器加一下zgc 监控
3) 需要联系sre给相应服务加一下zgc 监控
3.3 需要增加的falcon监控仪表盘

//回收周期
zgc.monitor/method=max,name=Collector_Garbage_Collection_Cycle,service=ai-operation-controller

//阶段停顿时间
zgc.monitor/method=avg,name=Phase_Pause_Mark_End,service=ai-operation-controller
zgc.monitor/method=avg,name=Phase_Pause_Mark_Start,service=ai-operation-controller
zgc.monitor/method=avg,name=Phase_Pause_Relocate_Start,service=ai-operation-controller

//转移前后堆大小
zgc.monitor/method=avg,name=Memory_Heap_Used_Before_Relocation,service=ai-operation-controller
zgc.monitor/method=avg,name=Memory_Heap_Used_After_Relocation,service=ai-operation-controller

//内存分配比例
zgc.monitor/method=avg,name=Memory_Allocation_Rate,service=ai-operation-controller

3.4 监控指标观察

process.cpu
cpu相比之前占用稍微降低，考虑到刚上线两天，继续观察
process.mem

“特别提到了3个视图，分别是Marked0、Marked1和Remapped，而且有趣的是这3个视图会映射到操作系统的同一物理地址。这就是ZGC中Color
Pointers的概念，通过Color Pointers来区别不同的虚拟视图。”

是配置内存4g的三倍，符合预期。因为zgc的着色指针会虚拟出三份虚拟空间，但实际占用只有一份
3. 接口监控
该接口的性能尖刺基本消失（之前由于 object copy耗时太长4s, 导致接口延时也会偶现4s），由于zgc并发转移，停顿时间非常小
4. 经验与总结

尽管现在垃圾回收器性能越来越好，给我们的code带来效率。但是我们还是得从源头来避免性能问题，注重代码规范。
需要升级java 11.0.8以上，并且升级相应的插件
falcon需要SRE添加相应的job