内容简介:2020年新年伊始,排查一个线上GC问题。最直观的现象就是,1月2号线上一个Elasticsearch查询服务突然报警,几乎同时业务反馈某实时报表数据查询页面报错。同时看到后台日志java.lang.OutOfMemoryError: GCoverheadlimitexceeded,Eurake注册服务页面也已经没有检测到心跳,主动把此服务从注册中心列表服务剔除。情况紧急,此服务集群节点第一次出现这种情况,而且最近迭代没有进行版本更新,有点措手不及。当即采取的措施是优先保证业务使用,先恢复服务,将原本-Xm
问题重现
2020年新年伊始,排查一个线上GC问题。最直观的现象就是,1月2号线上一个Elasticsearch查询服务突然报警,几乎同时业务反馈某实时报表数据查询页面报错。同时看到后台日志java.lang.OutOfMemoryError: GCoverheadlimitexceeded,Eurake注册服务页面也已经没有检测到心跳,主动把此服务从注册中心列表服务剔除。情况紧急,此服务集群节点第一次出现这种情况,而且最近迭代没有进行版本更新,有点措手不及。当即采取的措施是优先保证业务使用,先恢复服务,将原本-Xms128m -Xmx512m的值调大到 -Xms1024m -Xmx1024m,重启服务恢复正常,后台日志正常,看似一切正常。
原因排查
业务使用一段时间后又开始报错,通过分析页面Network请求后端接口发现,接口相应出现了超时。有些ES的查询居然耗时高达49S,线程与线程之间出现了卡顿的情况,卡顿时间很多在15S左右。
猜想原因服务在生产运行半年以上ES有一定数据量级1.由于对ES做了大的聚会查询操作,是不是ES性能出现了问题,检查ES本身资源使用情况,和响应均正常?2.是否服务代码有资源未能及时释放。
措施
1.对ES关键查询做了日志打印,启动脚本添加了对GC日志的打印,命令如下:-XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:/data/app/server/es-query-server/heapEs.log,调整了垃圾回收算法为并行执行-XX:ConcGCThreads 2.进一步扩大堆内存至 -Xms2048m -Xmx2048m。
3.将实时大报表查询做了临时下线处理,保留了两个轻量的列表查询。紧急发布服务,再次恢复正常。
问题定位与修复
第二天下午又出现报错问题,通过日志发现ES查询正常性能很好,排除ES相应导致的问题。那么问题就出现在自己服务代码本身的漏洞了,通过gcviewer分析了gc日志在某个时间段以后一直FGC,heap一直没有有效回收。之前的卡顿现象也可以解释了,fgc导致服务出现了Stop the world。
通过jmap -dump:live,file=dump_075.bin 133333命令获取
dump文件.JDK自带jvisualvm监控 工具 分析dump文件.
注意到dump文件最大的对象是一个char[]数组,而且里面都是请求对象,通过使用场景判断,不应该出现那么多对象,所以进一步推断是否出现了死循环,测试环境恢复了之前的实时数据查询的大列表,发现页面的查询列表出现时间数据无法展示的情况,进一步看后台日志,针对报错信息,定位到了一个日期计算夸年夸季度出现了条件不匹配导致死循环。
总结
性能问题的调优,往往很复杂,准确定位问题考验开发人员对底层熟悉程度,也考验对排查问题的工具的灵活运用。不经意的错误,特别容易忽略,多积累,研究底层原理,有助于排查复杂问题。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
URL 编码/解码
URL 编码/解码
HEX HSV 转换工具
HEX HSV 互换工具