记一次线上内存溢出问题排查

2018/08/15   

0. 背景

本次事故又是发生在KS身上,看来KS最近脾气不太好,想要休养休养呢。

事故现象:前端数据可视化模块全部白板,无法正常加载出来。

1. 问题定位

看到事故表象后,快速去查看了后台日志,发现有OutOfMemoryError关键字,但是提示信息不明确,就赶快通过ps拿到PID后,去通过jmap -histo:live PID查看内存中占比最高的对象是哪些。通过列表信息,发现内存中占比非常高的对象居然是:TaskLogTaskTraceLog对象。这两个对象是用来记录任务状态信息,既然是WEB端出现了OOM,那么只有一种可能,就是和查询有关,而用到这两个对象的是任务实时监控页面。

经过分析,发现是任务运行状态计算结果是根据用户相区分,同时又需要每5秒钟请求一次用户所有权限的任务状态信息,每10秒钟请求一次系统任务指标信息。这样明显不合理啊,正常应该是全局任务状态计算好,存储一份,然后根据用户权限去过滤拉取即可。

定位了问题后,首先进行了WEB的恢复操作,然后去重构了下任务实时监控数据获取的代码,自测 & QC测试通过后发布上线。最终问题得以解决,查询性能也好了很多。

Summary

  • 1)代码并不是实现了功能需求即可,还要考虑好边界情况,会带来哪些影响,产生什么结果

  • 2)线上问题定位过程是一个不断积累,逐渐成长的过程

  • 3)熟练掌握Linux命令是很重要的,总不能你要紧急处理线上问题了还要去百度或者Google一下命令吧?


一个正在技术专家成长道路上不断努力前进的程序员

(转载本站文章请注明作者和出处 buildupchao

Post Directory