火眼金睛破局ES伪慢查询
一、问题现象
服务现象
服务接口的TP99性能降低
ES现象
- YGC:耗时极其不正常, 峰值200+次,耗时7s+
- FULL GC:不正常,次数为1但是频繁,STW 5s
- 慢查询:存在慢查询5+
二 解决过程
1、去除干扰因素
- 从现象上看应用是由于某种原因导致JVM内存使用率不断增长,触发了频繁的YGC进而触发FGC(此时只是大胆的猜测)。
- 此时ES的JVM配置是JVM内存40G,使用CMS垃圾回收器。40G的内存使用CMS垃圾回收器性能显然不如G1更合适
- 找ES运维同学垃圾回收器由CMS修改为G1
(tips:不是所有的ES都适合G1,针对很多大查询的G1的Full GC会导致GC模式退化为串行扫描整个堆,导致几十秒甚至是分钟级别的暂停。这种长时间的暂停不仅影响用户的查询,还容易造成节点间的通信超时,导致master、dataNode脱离集群,影响集群稳定性。)
修改为G1后的GC变化:
- YGC:耗时极正常, 峰值35+次,耗时800ms
- FULL GC:正常,次数为0
- 慢查询:存在慢查询10+
2、查找问题
ES的JVM垃圾回收器调整后,杰夫接口的服务接口的性能并没有因为GC问题的解决而解决。
- 通过和ES侧同学的沟通了解到,这个ES集群的refresh极其异常,refresh:2w+。
- ES监控中的慢查询语句单独去执行并不慢
原因:
应用中和ES的交互使用的是3.1.9.RELEASE 版本的spring-data-elasticsearch的包,ES数据同步工作是通过该API的中的save方法进行保存数据的,如下图所示,该版本的save操作每次save后都会进行refresh操作
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-elasticsearch</artifactId>
<version>3.1.9.RELEASE</version>
为什么每次refresh会对查询产生影响呢,今天咱们也赶个时髦,让GPT给咱们回复下试试:
3、修复方案
-
升级spring-data-elasticsearch 的版本到4.x以上,由于spring-data-elasticsearch高本版不兼容低版本改动成本较大,该项目中的所有涉及API操作的地方都需要改动
-
save操作改用operation进行操作(目前选择的该方案,改动较少)
慢查询已经消失
refresh的次数也降了下来
三、问题解决
最终的业务服务接口性能正常了。
教员常说我们总是被经验主意和投机主义左右我们的思想,破局这一问题的根本解决方式是只有实事求是,实践是真理的标准。
作者:京东物流 王义杰
来源:京东云开发者社区 自猿其说Tech 转载请注明来源