JVM 内存大对象监控和优化实践

一、问题描

音乐业务中，core服务主要提供歌曲、歌手等元数据与用户资产查询。随着元数据与用户资产查询量的增长，一些JVM内存问题也逐渐显露，例如GC频繁、耗时长，在高峰期RPC调用超时等问题，导致业务核心功能受损。

图1 业务异常数量变化

二、分析与解决

通过对日志，机器CPU、内存等监控数据分析发现：

YGC平均每分钟次数12次，峰值为24次，平均每次的耗时在327毫秒。FGC平均每10分钟0.08次，峰值1次，平均耗时30秒。可以看到GC问题较为突出。

在问题期间，机器的CPU并没有明显的变化，但是堆内存出现较大异常。图2，黄色圆圈处，内存使用急速上升，FGC变的频繁，释放的内存越来越少。

图2 老年代内存使用异常

因此，我们认为业务功能异常是机器的内存问题导致的，需要对服务的内存做一次专项优化。

步骤1 JVM优化

以下是默认的JVM参数：

如果不指定垃圾收集器，那么JDK 8默认采用的是Parallel Scavenge（新生代） +Parallel Old（老年代），这种组合在多核CPU上充分利用多线程并行的优势，提高垃圾回收的效率和吞吐量。但是，由于采用多线程并行方式，会造成一定的停顿时间，不适合对响应时间要求较高的应用程序。然而，core这类的服务特点是对象数量多，生命周期短。在系统特点上，吞吐量较低，要求时延低。因此，默认的JVM参数并不适合core服务。

根据业务的特点和多次对照实验，选择了如下参数进行JVM优化（4核8G的机器）。该参数将young区设为原来的1.5倍，减少了进入老年代的对象数量。将垃圾回收器换成ParNew+CMS，可以减少YGC的次数，降低停顿时间。此外还开启了CMSScavengeBeforeRemark，在CMS的重新标记阶段进行一次YGC，以减少重新标记的时间。

图3 JVM优化前后的堆内存对比

优化后效果如图3，堆内存的使用明显降低，但是Dubbo超时仍然存在。

我们推断，在业务高峰期，该节点出现了大对象晋升到了老年代，导致内存使用迅速上升，并且大对象没有被及时回收。那如何找到这个大对象及其产生的原因呢？为了降低问题排查期间业务的损失，提出了临时的故障转移策略，尽量降低异常数量。

步骤2 故障转移策略