Netflix-Generation ZGC Test

Intro

原文来自于 Origin Blog

分代 ZGC

是 jdk21 中已经 released 的关键技术, JEP439-Generational ZGC

Netflix 在一些业务上已经落地了 Generational ZGC 和 Jdk 21

减少了 tail latencies

tail latencies 一般是指尾部延迟，其实就是 95%, 99% 这样的业务指标, 用来作为 高压情况下对性能响应体验的指标
Netflix 认为 GC 导致的 stw 会造成 p99.99 这种尾部指标飙高的情况，个人理解如下:
- 尾部指标其实就是特别少的异常情况, GC 确实是每隔一段时间搞一次 ;
- GC 造成的 stw 很难在链路追踪系统中反应出来, 历史上经常碰见链路追路部分卡了，但是不知道为啥，这个时候 也许查询下 GC 日志否是 stw 是个好习惯 ;
- 简单来说, GC 造成的流量，重试，延迟都属于 Nosie, 噪音, 不能反应出系统真实的压力

Netflix 的 GC 监控指标, 理解指标

Allocation Rating: 对象的分配速率, 内存需求方
CodeCache_GC_Threshold: CodeCache 区域 GC的阈值.
G1_Evacuation_Pause: 新生代GC 或者 MixedGC 使用复制算法把存活的对象复制到新的 Regioin, 这个阶段是需要 STW 的，也是 STW 的主要原因
G1_Humongonuse_Allocation: 需要为大对象找到连续的内存，需要短暂的 STW 来完成
GCLocker_Initited_GC: 这种垃圾收集可能在处理了大量的Humongous对象或触发了GC Locker后启动, 比较特殊的机制
Metadata_GC : 元数据的加载也会引发 GC
…

Efficiency

最初的时候，Netflix 的工程师认为使用分代 ZGC , 需要在应用吞吐量（application throughput）和 STW 之间做出权衡 . 由于 jvm 的如下机制:

实际中，发现不需要做出太多的 trade-off, 因为在 cpu 利用率相等的前提下, 分代 zgc 在各种指标上都是完全的胜利

Operational Simplicity

Memory Overhead