一次故障的查找记录

作者: zorkelvll | 来源:发表于2019-03-23 19:27 被阅读0次
    image

    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??????

    相关文章

      网友评论

        本文标题:一次故障的查找记录

        本文链接:https://www.haomeiwen.com/subject/nhfevqtx.html