转载

记一次ES的GC问题

点击上方 “ 匠心零度 ” ，选择“ 设为星标 ”

做积极的人，而不是积极废人

来源： https://blog.csdn.net/qq_16681169

一. 问题背景
二. 问题排查
三. 解决方案
四. 问题总结

一. 问题背景

在双十一时，有用户反馈推广平台物料列表出现了耗时严重的情况。筛选排序系统出现过耗时严重的情况，根据业务系统的筛选排序慢接口的traceId, 我们分析了一下请求链路上的瓶颈是ES.

二. 问题排查

首选我们在监控平台上确认了一下ES的访问流量，发现流量曲线变化不大，说明不是ES读请求压力突增导致的。

接着我们看了ES的bigdesk监控，发现有不少Full GC，与此同时查看了GC日志，发现日志里有比较频繁的CMS。

然后分析了下日志的内容，发现cms remark这个阶段时间特别长，甚至有3-5s的情况，而且这个阶段是stop the world的，会影响用户线程的工作。

remark如果耗时较长，通常原因是在cms gc已经结束了concurrent-mark步骤后，旧生代的引用关系仍然发生了很多的变化，旧生代的引用关系发生变化的原因主要是：

在这个间隔时间段内，新生代晋升到旧生代的对象比较多；
在这个间隔时间段内，创建出来的对象又比较多，年轻带也是cms的

这个阶段会导致第二次stop the word，该阶段的任务是完成标记整个年老代的所有的存活对象。

这个阶段，重新标记的内存范围是整个堆，包含_young_gen和_old_gen。为什么要扫描新生代呢，因为对于老年代中的对象，如果被新生代中的对象引用，那么就会被视为存活对象，即使新生代的对象已经不可达了，也会使用这些不可达的对象当做cms的“gc root”，来扫描老年代；因此对于老年代来说，引用了老年代中对象的新生代的对象，也会被老年代视作“GC ROOTS”:当此阶段耗时较长的时候，可以加入参数-XX:+CMSScavengeBeforeRemark，在重新标记之前，先执行一次ygc，回收掉年轻带的对象无用的对象，并将对象放入幸存带或晋升到老年代，这样再进行年轻带扫描时，只需要扫描幸存区的对象即可，一般幸存带非常小，这大大减少了扫描时间

由于之前的预处理阶段是与用户线程并发执行的，这时候可能年轻带的对象对老年代的引用已经发生了很多改变，这个时候，remark阶段要花很多时间处理这些改变，会导致很长stop the word，所以通常CMS尽量运行Final Remark阶段在年轻代是足够干净的时候。

gc root，cms会扫描年轻带中持有老年代对象的引用，如果年轻带有大量引用需要被扫描，会让Remark阶段耗时增加

为什么remark阶段这么长时间？就是一次cms 周期内，并发标记后到remark这个期间jvm堆内存对象变化很大。看了下remark的时间，对应我们的业务日志里就是一大波 es bulk的操作。对应Bigdesk观察，几秒的卡顿基本都出现在一大波 es bulk操作时间吻和。

分析了bulk引起了remark耗时是因为数据流的物料同步时有些地方写的不够好导致的。