记一次内存无法回收导致频繁fullgc机器假死的思路

确定挂机 络绎不绝的来不同类型的bug

当bug滚滚而来时,不要怀疑,你的发布的应用基本是不可用状态了。
观察哨兵监控数据,特别是内存打到80%基本就挂机了,或者监控数据缺失也基本是挂机了。
此时应当马上决断:

  • 通知运营暂停操作(大多数是因为后台应用导致的,纯经验猜测,因为你也不可能让外部用户停止操作)
  • 重启大多数机器,保留一台机器保存现场(下线机器)。

实例:

  • 友品app首页有频率的失败
  • 运营提bug,后台导出每次都不可用,其他的偶现不可用

找到原因 把此问题复现出来

根据各方面的反馈,加自身的迭代,找寻线索,积极在预发尝试,以求确定病根。

  • 最近上线内容
  • 最近使用操作
  • 最近超时接口

实例:
见上描述,导出每次不可用,马上在预发复现此问题。
感谢运营的反馈,此处可总结,运营在使用系统过程中出现问题要及时反馈,不要害羞。

确定问题根源

线上一般内存偏大,有6-8G,用jmap下来文件很大,也不易分析。
此时可转换思路,创建一个干净的环境,调试此固定逻辑。
这里的问题是线上数据怎么来?

  1. dubbo 直连(不建议)
  2. 通知运维导出线上数据

搭建本地环境,调试固定逻辑:

  1. 相关业务逻辑迁移到本地(线上数据来源是2,此时需要导入数据,封装dao)
  2. 本地设置 -xms-xmx为20M(设置本地使用内存)
  3. jmap -histo 77710 >./Downloads/15.log 导出内存文件查看内存消耗
  4. 分析并解决,如果是自己责任内则解决,否则抛出(纯能力和经验)

实例:
在本地环境调试后发现导出正常,20M内存可以支撑导出37万条数据没有问题。
此时回过头去看线上逻辑代码,比本地多一个文件加水印,此时修改代码,再文件生成后打印一条日志,部署预发。
发现文件可以生成,但文件加水印迟迟未结束。
去掉文件加水印后部署预发,导出正常。
此时排查出问题出在文件加水印,此为中间件的工具,故而不做解决,直接去掉加水印提测。并报告问题给相应人。

总结

  1. 判断是否挂机
  2. 通知运营暂停操作
  3. 重启大多数机器,保留一台机器保存现场
  4. 找到那个操作引起的此现象
  5. 转为本地调试,找寻问题根源
  6. 解决或抛出
posted @ 2019-06-18 09:44  wade&luffy  阅读(794)  评论(1编辑  收藏  举报