火眼金睛破局ES伪慢查询 | 京东物流技术团队

一、问题现象

服务现象

服务接口的TP99性能降低

火眼金睛破局ES伪慢查询 | 京东物流技术团队_第1张图片

ES现象

  • YGC:耗时极其不正常, 峰值200+次,耗时7s+
  • FULL GC:不正常,次数为1但是频繁,STW 5s
  • 慢查询:存在慢查询5+

火眼金睛破局ES伪慢查询 | 京东物流技术团队_第2张图片

二 解决过程

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+

火眼金睛破局ES伪慢查询 | 京东物流技术团队_第3张图片

2、查找问题

ES的JVM垃圾回收器调整后,杰夫接口的服务接口的性能并没有因为GC问题的解决而解决。

  • 通过和ES侧同学的沟通了解到,这个ES集群的refresh极其异常,refresh:2w+。

火眼金睛破局ES伪慢查询 | 京东物流技术团队_第4张图片

  • ES监控中的慢查询语句单独去执行并不慢

火眼金睛破局ES伪慢查询 | 京东物流技术团队_第5张图片

原因:

应用中和ES的交互使用的是3.1.9.RELEASE 版本的spring-data-elasticsearch的包,ES数据同步工作是通过该API的中的save方法进行保存数据的,如下图所示,该版本的save操作每次save后都会进行refresh操作

org.springframework.data
spring-data-elasticsearch
3.1.9.RELEASE


火眼金睛破局ES伪慢查询 | 京东物流技术团队_第6张图片

为什么每次refresh会对查询产生影响呢,今天咱们也赶个时髦,让GPT给咱们回复下试试:

火眼金睛破局ES伪慢查询 | 京东物流技术团队_第7张图片

火眼金睛破局ES伪慢查询 | 京东物流技术团队_第8张图片

火眼金睛破局ES伪慢查询 | 京东物流技术团队_第9张图片

3、修复方案

  • 升级spring-data-elasticsearch 的版本到4.x以上,由于spring-data-elasticsearch高本版不兼容低版本改动成本较大,该项目中的所有涉及API操作的地方都需要改动

  • save操作改用operation进行操作(目前选择的该方案,改动较少)

火眼金睛破局ES伪慢查询 | 京东物流技术团队_第10张图片

慢查询已经消失

火眼金睛破局ES伪慢查询 | 京东物流技术团队_第11张图片

refresh的次数也降了下来

火眼金睛破局ES伪慢查询 | 京东物流技术团队_第12张图片

三、问题解决

最终的业务服务接口性能正常了。

教员常说我们总是被经验主意和投机主义左右我们的思想,破局这一问题的根本解决方式是只有实事求是,实践是真理的标准。

火眼金睛破局ES伪慢查询 | 京东物流技术团队_第13张图片

作者:京东物流 王义杰

来源:京东云开发者社区 自猿其说Tech 转载请注明来源

你可能感兴趣的:(数据库,elasticsearch,大数据,搜索引擎)