分类 标签 存档 社区 博客 友链 GitHub 订阅 搜索

一次故障的查找记录

276 浏览




ZERO

    持续更新 请关注:https://zorkelvll.cn/blogs/zorkelvll/articles/2019/01/16/1547619476722

背景

     在一次某个项目 sp-jar 运行过程中,总是在过一段时间后该 jar 进程总是会 “无缘无故”(怎么可能是无缘无故呢,一切都是有原因的,只不过自己还不知道而已)结束掉或者被杀死,因此决定进行一次进行查找以自我地提升,毕竟在很小的一个以外包 demo 服务为导向的非技术性公司,这样的机会也是非常少的!

     既然,难得有这样的实战机会,就不应该再仅仅停留在理论上对各类故障定位解决、JVM 分析的理论层面上! 于是,决定进行一番探索!

1、系统日志

  • 首先,在该应用运行过程中,记录其运行的 PID 号为 24296

  • 在系统日志 / var/log/messages 中定位原因,执行命令

    cd /var/log

    cat messages | grep 24296

imagepng

  • 如查询结果,显然知道是出现了 OOM 异常,被系统杀死了;接下来,就是定位是应用中哪段代码导致的该异常

分析插曲

毕竟第一次摸索着实践,也没啥有经验人士面基,因此分析以为:

  • 第一次以为,在应用发生关闭的时候,是系统内存超了;而这个时候,系统会自动查找一个内存占用最大的进程也即 sp 给杀死(=> 但是 sp 被杀死,并不一定就是因为 sp 这个应用而导致的系统内存超出的,也有可能是其他的应用导致的系统内存超出,然后系统去杀死了内存占用最大的这个 sp)
  • =>,因此决定去查看上面那一段报错之前的一段 log 信息内容,只能 vim messages 加上搜索时间点”Jan 16 02:34:34“,去查看详细的时间点的内容如下,

imagepng

虽然也看不太懂(汗颜)

  • 再次分析,通过 zabbix 上系统的内存监控,发现系统内存好像并没有超出系统最大值,因此上面的以为是系统内存超出了而杀死的占用最大的内存进程,说法不一定是对的 (其实,zabbix 上的时间内存飙升的那一个时间点刚好上 02:34:34 + 8 差不多这个时间),

=> 另外疑惑的是,在这一时刻,系统内存确实是在飙升的,但是根据监控图显示来说的系统内存也还是有的,仍然有 6G 多的内存可供使用!一方面系统中被使用的内存确实突增,另一方面,确实使用也没有爆掉整个系统的内存

=> 更进一步地思考,观察 zabbix 中该系统使用内存的走势来说,进一步发现被使用的最多也就是达到 2G!因此,考虑:或者操作系统本身安全考虑导致的某个地方的配置内存上限,或者 JVM 中的内存最大参数 Xmx 设置

imagepng

  • 然后,因此也有可能该 sp 这个应用本身的最大可用内存超了,即重新设置 Xmx??????




评论  
留下你的脚步
推荐阅读