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
![](https://img.haomeiwen.com/i11380090/b9b03f6b9c4244b9.png)
- 如查询结果,显然知道是出现了OOM异常,被系统杀死了;接下来,就是定位是应用中哪段代码导致的该异常
分析插曲:
毕竟第一次摸索着实践,也没啥有经验人士面基,因此分析以为:
- 第一次以为,在应用发生关闭的时候,是系统内存超了;而这个时候,系统会自动查找一个内存占用最大的进程也即sp给杀死(=>但是sp被杀死,并不一定就是因为sp这个应用而导致的系统内存超出的,也有可能是其他的应用导致的系统内存超出,然后系统去杀死了内存占用最大的这个sp)
- =>,因此决定去查看上面那一段报错之前的一段log信息内容,只能vim messages加上搜索时间点”Jan 16 02:34:34“,去查看详细的时间点的内容如下,
![](https://img.haomeiwen.com/i11380090/6e2bfd45c52613bf.png)
虽然也看不太懂(汗颜)
- 再次分析,通过zabbix上系统的内存监控,发现系统内存好像并没有超出系统最大值,因此上面的以为是系统内存超出了而杀死的占用最大的内存进程,说法不一定是对的
(其实,zabbix上的时间内存飙升的那一个时间点刚好上02:34:34 + 8差不多这个时间),
=>另外疑惑的是,在这一时刻,系统内存确实是在飙升的,但是根据监控图显示来说的系统内存也还是有的,仍然有6G多的内存可供使用!一方面系统中被使用的内存确实突增,另一方面,确实使用也没有爆掉整个系统的内存
=>更进一步地思考,观察zabbix中该系统使用内存的走势来说,进一步发现被使用的最多也就是达到2G!因此,考虑:或者操作系统本身安全考虑导致的某个地方的配置内存上限,或者JVM中的内存最大参数Xmx设置
![](https://img.haomeiwen.com/i11380090/000b988575a42796.png)
- 然后,因此也有可能该sp这个应用本身的最大可用内存超了,即重新设置Xmx??????
网友评论