一次故障的查找记录

背景

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

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

1、系统日志

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

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

  cd /var/log

  cat messages | grep 24296

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

分析插曲：

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

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

虽然也看不太懂（汗颜）

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

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

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

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