火眼金睛破局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 转载请注明来源