一、问题现象

服务现象

服务接口的 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 转载请注明来源