在双十一期间，由于用户反馈推广平台物料列表加载缓慢，排查后发现ES存在Full GC问题。通过监控和日志分析，发现CMS的remark阶段耗时较长，主要原因是并发标记后到remark期间内存对象变化大，尤其是ES bulk操作引发的。解决方案包括调整GC参数，如增加CMS回收线程数，开启并行remark，以及优化业务场景中的bulk操作，减少对CMS 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”，来扫描老年
最低0.47元/天 解锁文章
扫一扫
370
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
