一、问题现象
服务现象
服务接口的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的次数也降了下来
三、问题解决
最终的业务服务接口性能正常了。
教员常说我们总是被经验主意和投机主义左右我们的思想，破局这一问题的根本解决方式是只有实事求是，实践是真理的标准。
