[转载] 记一次 ES 的 GC 问题

目录

  • 一. 问题背景

  • 二. 问题排查

  • 三. 解决方案

  • 四. 问题总结

一. 问题背景

在双十一时,有用户反馈推广平台物料列表出现了耗时严重的情况。筛选排序系统出现过耗时严重的情况,根据业务系统的筛选排序慢接口的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耗时是因为数据流的物料同步时有些地方写的不够好导致的。

三. 解决方案

1、对GC参数的调整

a.增加了CMS回收的线程数

因为我们是32 核的cpu ,cpu 利用率用bigdesk观察还是很低的,

5%左右。-XX:ParallelGCThreads= N

-XX:ParallelCMSThreads= M

调整这2个参数都可以,它们的关系:

ParallelCMSThreads = (ParallelGCThreads + 3)/4)

调整后情况缓解了一些,remark还是有3,4秒的情况。

b.开启了并行remark

 -XX:+CMSParallelRemarkEnabled

c.强制 remark之前开始一次minor gc,从而减少remark阶段扫描年轻代gc root的开销

-XX:+CMSScavengeBeforeRemark

2、对业务场景中bulk操作的调整

部分场景一次bulk 操作就写1条数据或者很少的数据,在业务里修改了代码逻辑,将bulk操作合并写入更多的数据,减少bulk操作IO的操作对CMS GC的影响。

四. 问题总结

1、遇到问题可以借助监控和日志,分析特征帮助快速定位问题

2、有时候出现性能问题,除了考虑技术上的升级,还可以考虑业务上相应的调整,在某些场景业务调整效果可能更佳 ?

作者:zxcodestudy
来源:CSDN
原文链接:blog.csdn.net/qq_16681169/article/...

讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!