服装公司网站建设开题报告,网站建设内容保障制度,较好的网站模板,装修设计公司快餐店一、问题现象
服务现象
服务接口的TP99性能降低 ES现象
YGC#xff1a;耗时极其不正常, 峰值200次#xff0c;耗时7sFULL GC#xff1a;不正常,次数为1但是频繁#xff0c;STW 5s慢查询#xff1a;存在慢查询5 二 解决过程
1、去除干扰因素
从现象上看应用是由于某种…一、问题现象
服务现象
服务接口的TP99性能降低 ES现象
YGC耗时极其不正常, 峰值200次耗时7sFULL 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次耗时800msFULL GC正常,次数为0慢查询存在慢查询10 2、查找问题
ES的JVM垃圾回收器调整后杰夫接口的服务接口的性能并没有因为GC问题的解决而解决。
通过和ES侧同学的沟通了解到这个ES集群的refresh极其异常refresh2w。 ES监控中的慢查询语句单独去执行并不慢 原因
应用中和ES的交互使用的是3.1.9.RELEASE 版本的spring-data-elasticsearch的包ES数据同步工作是通过该API的中的save方法进行保存数据的如下图所示该版本的save操作每次save后都会进行refresh操作
groupIdorg.springframework.data/groupId
artifactIdspring-data-elasticsearch/artifactId
version3.1.9.RELEASE/version 为什么每次refresh会对查询产生影响呢今天咱们也赶个时髦让GPT给咱们回复下试试 3、修复方案 升级spring-data-elasticsearch 的版本到4.x以上由于spring-data-elasticsearch高本版不兼容低版本改动成本较大该项目中的所有涉及API操作的地方都需要改动 save操作改用operation进行操作目前选择的该方案改动较少
慢查询已经消失 refresh的次数也降了下来 三、问题解决
最终的业务服务接口性能正常了。
教员常说我们总是被经验主意和投机主义左右我们的思想破局这一问题的根本解决方式是只有实事求是实践是真理的标准。
