JVM和机器规格调优在有赞的实践

前言

2022年年初至今，团队持续在给业务应用做性能优化，主要目标是提高业务应用稳定性和降低业务应用的机器成本。到现在，代码层面的优化已经到了一定的瓶颈。所以就把优化的思路伸向了JVM的调优。有赞目前所有的Java应用采用的JDK版本是1.8.0_201，这个版本支持多个垃圾回收机制，比如CMS和G1等，而在有赞，除了个别应用有调整成G1垃圾收集机制的需求以外，其他所有应用都还采用着ParNew+CMS。有赞也将从G1身上挖掘出能够提供应用稳定性和降本的价值。

一、稳定性问题分析

近期陆续会收到一些业务应用开发的反馈，他们的困扰来自于告警问题，应用非常不稳定。主要可以概括为两类问题：

1. Dubbo线程池打满的告警
2. 上游调用方调用超时异常日志的告警

第一类线程池打满的异常告警问题，导致该问题比较常见的原因有瞬时流量、比较耗时的同步操作导致线程阻塞、线程之间的锁竞争等；导致第二类问题的原因有网络抖动、各种Provider响应慢的原因。

从监控数据观察，出现问题的时间点，流量并没有激增，由此排除了流量带来的影响。并且观察了Provider的P99和avg RT，发现在这个时间点的确出现了增高，这就能解释上游会调用超时的问题，基本确定是Provider响应慢导致的，排除了网络因素。重点放在观察Provider上，利用JFR抓了一下，能看到一些阻塞点，但是这些阻塞点并不会引起RT这么大的抖动，由此可见应该还有别的因素导致出现阻塞。随即联想到JVM垃圾回收时的STW可能会影响用户线程。查看了JVM的监控数据以及GC Log，发现事发时间与出现Full GC时间吻合。下图为JVM监控数据：

从图中可以看到在有几个时间点Full GC高达5次，并且耗时累计50s以上，Full GC是完全STW的，所以就出现了线程池打满、耗时长的一些列问题。因为采用的是CMS垃圾回收机制，流量并没有太大的波动，并且从一分钟内出现5次Full GC，可以大致确定是产生了大对象，直接进入了老年代，才这么频繁的触发Full GC，产生大对象有很多情况导致的，比如CMS的Young GC中存在的碎片化问题导致空间分配效率和空间利用率比较低，最终导致大对象找不到可用的空间分配空间、CMS的堆内存空间分配是连续的以及业务上本身就出现非常庞大的对象等。这里暂时不考虑业务上庞大的对象，因为拆解庞大的对象，可能会面临业务逻辑的改动和重新设计，主要还是从JVM本身来进行调优。

二、利用G1解决稳定性问题

上述提到有关CMS的几个问题，在G1中都被完美的解决了，首先G1采用的分区模型，把堆内存分成若干个region，可以保证这些空间区域不连续，并且与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实现的垃圾回收，G1在进行Evacuation操作时，并不会产生内存空间碎片，这在一定程度上解决了CMS分配大对象时无法找到连续内存空间而触发GC的问题。

除此之外，G1的region有一种Humongous region类型，专门用于存放大对象，G1在触发Global Concurrent Marking操作后，Humongous region也会被扫描一遍，如果大对象确认可以回收，会在Mixed GC期间将该对象回收，相对于退化到Serial old GC进行Full GC，STW的时间会短很多。

从上述分析得知，这些问题都可以通过改变垃圾回收机制为G1来解决。去掉了以往的GC相关的JVM参数后，加入了以下G1的相关的配置参数：

-XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20

相比于CMS的配置，G1的配置简单了很多，其中包括-XX:MaxGCPauseMillis等值都暂时按照默认200ms来使用。变更完后，观察了几天，发现超时，线程池打满的情况几乎消失了，下图是变更完后的JVM监控数据，从图中可以看到Full GC完全消失了：

三、G1的局限性

上述试点应用的单个容器实例的机器规格是4c8g，从试点应用的表现来看，稳定性提高了许多。但是目前并不能将所有的应用都升级为G1，尤其是机器规格较小的应用，比如1c2g、2c4g的应用。这就涉及到G1的局限性问题。

G1在堆内存较小的情况下，吞吐量、回收的效率等各方面表现都不如CMS，这是为什么？

一个原因是G1采用分区模型，它用于跨region的对象引用所采用的Remembered Set（简称Rset）数据结构，主要记录了哪个Region的哪个Card上的对象引用了本Region中的对象。导致在不同region间的对象引用需要额外的内存进行记录，虽然CMS也有类似Rset的机制，它就是在Card Table脏卡对应的老年代区域，该区域老年代对象会引用年轻代对象。与G1的思想刚好相反，因为G1中是记录谁引用了自己，而CMS则是记录了引用了谁，相比较而言，G1的扫描标记效率要高于CMS，但是如果该region的对象是热点对象，则Rset记录的内容也会随之增大，除此之外，Rset还受到region数量和大小的影响。所以G1一部分堆内存被用于Rset，Rset的设计导致G1的内存使用需要多于CMS。一旦堆空间不够大，G1将会更容易导致Full GC，因为相比CMS而言，可存放的对象空间更少，从而导致G1的表现劣于CMS。

第二个原因是堆很小的情况下，G1的预测模型优势就无法发挥出来，并且由于堆内存的过小，每个region也会很小，达到最小的1M时，可能会出现大量的Humongous 对象，而Humongous对象过多，会导致频繁的Mixed GC，并且非常容易触发Full GC。

G1除了需要更多的内存空间以外，还会带来CPU的使用率增加，导致容器实例的CPU水位上升，因为 G1 除了 Write Barrier 来更新维护Card Table以外，还为了实现SATB算法，需要使用Write Barrier来跟踪并发时的指针变化情况。除了Card Table的维护损耗以外，G1还需要维护Rset，当引用关系发生改变时，G1需要更新Rset，G1为了能够异步更新Rset，引入了Dirty Card Queue（DCQ），DCQ中存放着引用关系更新的任务，在G1中会创建一个用于处理这些任务的线程池，这些线程称为 Refine 线程。使用 Refine 线程来消费 DCQ ，从而完成引用关系的记录并更新RSet。如果 Refine 线程忙不过来，GC线程以及应用线程也会被用于协助更新RSet。

四、放大G1的优势

从上述分析可知在堆大小足够的情况下，使用G1才更有优势和收益。目前核心的应用最大的机器规格也是4c8g，分配给堆的大小是4G，设想如果提高机器规格，那么将会让G1发挥更大的优势，尤其是在停顿时间上发挥更大的价值。但是调大机器规格后，成本近乎翻了一倍，为了保证成本能够不变甚至有所下降，就必须缩减应用在生产环境的实例数量，比如应用A在调整前部署了100个4c8g的容器实例，调整后应该变为50个8c16g的容器实例，并且通过调优，希望能缩小到少于50个实例。这样才能达到节省成本+稳定性提升的效果。

在扩大机器规格和缩减实例数的操作过程中，有个必须重视的事情，那就是单机的流量将会翻倍，调整前100个容器实例承担100%的流量，现在只有50个容器实例，却要承担100%的流量，所以对应的许多配置参数要调整，包括应用所依赖的一些中间件组件涉及到的参数、业务自身的参数等。下面是详细的操作步骤：

1 . 整理业务应用所依赖的中间件组件：比如dubbo、http、消息队列、DB、KV、限流组件等，dubbo服务需要扩大Dubbo线程的数量。

a . Dubbo服务的线程数，需要确认在实例缩小后原有的线程数是否能满足目前的流量。一般需要扩大Dubbo线程的数量到一倍，如果平时就已经在Dubbo线程池满的边缘，在一倍的基础上继续增加。

b . HTTP服务的线程数，需要确认在实例缩小后原有的线程数是否能满足目前的流量。一般需要扩大HTTP线程的数量到一倍，如果平时就已经在HTTP线程池满的边缘，在一倍的基础上继续增加。

c . 消息队列则主要需要分消费者和生产者考虑，如果是消费者，实例缩小以后，如果消费速率远远跟不上消息生产的速率，需要扩大消费线程，如果由于前置操作的的线程数放大后，比如dubbo服务的线程数放大后，生产消息的速度提高了，但是都阻塞在让消息队列投递的地方，就需要扩大生产者的线程。

d . DB、KV则主要关注的是连接池内的连接数量是否足够，比如重度依赖KV的应用，则注意KV是否会达到瓶颈，如果会达到瓶颈，则需要调大连接数。

e . 限流组件：限流组件需要单独考虑，一般因为单机流量扩大了一倍，限流的阀值也需要相应扩大一倍。

2 . 整理出业务自定义的线程池，该线程池主要是业务自己定义的业务线程池，评估是否需要扩大线程数量，主要考虑这些线程池的使用场景，如果经常出现瓶颈，需要扩大一倍线程数量。

3 . 升级规格至相同数量的8c16g

4 . QA以及PRE 优先验证业务影响。如正常再继续操作线上。

5 . 线上发布后，观察业务是否正常、RT是否正常、CPU占用率、内存占用率是否正常、GC是否符合预期（每次Young gc 应该在200ms以下）。如正常，根据情况缩小实例至原有实例的一半，尽量分步缩小，逐步观察。

经过对几个核心应用的试点后，升级机器规格、缩减一半实例，并且改为G1后，由于框架和中间件SDK的Runtime损耗被复用，以及一些系统资源的复用，发现CPU水位还有所下降，所以对这些应用继续进行了实例的缩减，缩减到调优前的水位为止，效果如下：

• 应用A：180 台 4c8g -> 80 台 8c16g
• 应用B：250 台 4c8g -> 110 台 8c16g
• 应用C：170 台 4c8g -> 80 台 8c16g

虽然应用的成本降低了，但是这里还需要考虑到kubernetes的node分配容器实例产生的碎片问题，尤其是分配的容器实例规格越大，产生的碎片也就越大，所以需要计算好碎片的影响。除了成本降低以外，稳定性问题也得到了解决，其中部分应用Young GC次数相比最初的CMS下降3倍，Full GC直接降低为0，Max RT 降低了一半，RT毛刺的问题得到了非常好的优化。

五、未来

适用的应用整体的优化效果虽然好，但是正如前面所说，并不是所有的应用都适合这样做，为此，应用的部署情况采用了三种模式：

1. 升级机器规格、并且调整垃圾回收机制为G1：针对容器实例数多，一般超过40个容器实例，生产环境所需的机器规格为4c8g。这部分应用往往是一些核心应用。
2. 垃圾回收机制调整为G1：针对容器实例数较少、生产环境所需的机器规格为4c8g。
3. 继续使用CMS：针对容器实例数少、生产环境所需的机器规格较小（1c2g/2c4g）

除此之外，G1在不同的JDK版本也有不同的优化，所以在未来会调研高版本的OpenJDK，来了解是否有一些优化空间，如果存在一些优化空间，将会考虑升级OpenJDK来让G1产生更多的价值。