一次故障的查找记录

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