一次线上OOM故障排查经过
2014-03-06 13:05
1326 查看
转贴:http://my.oschina.net/flashsword/blog/205266
本文是一次线上OOM故障排查的经过,内容比较基础但是真实,主要是记录一下,没有OOM排查经验的同学也可以参考。
所以我们首先怀疑的是网络问题,打电话跟运维确认,运维说网络问题的可能性几乎为0,因为我们的机器是虚机,宿主机上的其他设备都运转正常。程序问题的可能性更大。继续从应用日志和tomcat的catalina.out中查找日志,发现有一些OutOfMemoryError异常。实际上,出现这个异常就代表内存不够了。
我们使用cat(公司的Java监控平台,已开源https://github.com/dianping/cat)查看堆使用的情况,看到如下的东西:
Memory Free已经接近了0,同时产生了大量的fullgc。
回到之前的连接timeout,我们知道,Java的连接timeout,除了网络传输的时间,也包括了Java程序处理的时间,所以OOM导致timeout也不奇怪了。
首先可用的是
这个命令会将内存中最终保存的对象列出来。
其中”[“表示数组,例如”[B"是byte[],具体可以看
但是这个只能粗略定位原因,如果要仔细分析,需要知道是哪些个对象持有了它,这个时候,就需要dump内存下来,再离线分析了。
dump内存的命令是:
此操作异常耗时,我跟运维在假死的机器上尝试了几次,竟然把tomcat进程干掉了,使用时还是小心为妙…跟同事讨论,认为
我这里使用
这里选择“计算保留大小”。这个保留大小是递归计算实例之间的依赖,得到的总大小。因为去掉了循环依赖,所以并不完全准确,但是用于排查够了。选择保留大小最大的实例,一般就是罪魁祸首了!
最后排查出的结果,是公司的RPC中间件使用了ThreadLocal来保存一个context,但是最后却没有释放。按照架构组的说明,升级了版本,问题解决!
本文是一次线上OOM故障排查的经过,内容比较基础但是真实,主要是记录一下,没有OOM排查经验的同学也可以参考。
现象
我们之前有一个计算作业。最近经常出现不稳定,无法正常响应的情况。具体表现是:各种连接超时,从mysql、mongodb和zookeeper到netty,能超时的都超时过了。其他看不到太多有效的异常。所以我们首先怀疑的是网络问题,打电话跟运维确认,运维说网络问题的可能性几乎为0,因为我们的机器是虚机,宿主机上的其他设备都运转正常。程序问题的可能性更大。继续从应用日志和tomcat的catalina.out中查找日志,发现有一些OutOfMemoryError异常。实际上,出现这个异常就代表内存不够了。
我们使用cat(公司的Java监控平台,已开源https://github.com/dianping/cat)查看堆使用的情况,看到如下的东西:
Memory Free已经接近了0,同时产生了大量的fullgc。
回到之前的连接timeout,我们知道,Java的连接timeout,除了网络传输的时间,也包括了Java程序处理的时间,所以OOM导致timeout也不奇怪了。
工具和排查
之前JVM分析做的很少,在同事的帮助下,结合一点资料,完成了基本的分析。首先可用的是
1 | jmap -histo PID |
其中”[“表示数组,例如”[B"是byte[],具体可以看
Class.getName()的Javadoc。
但是这个只能粗略定位原因,如果要仔细分析,需要知道是哪些个对象持有了它,这个时候,就需要dump内存下来,再离线分析了。
dump内存的命令是:
1 | jmap -dump:format=b,file=/home/admin/dump.bin PID |
jmap -dump实际上也是往运行的JVM实例发送一个dump请求,所以如果实例内存不足,dump很可能会失败。比较好的做法是先降低一部分负载(比如把线上的机器先切下线)再试。
我这里使用
VisualVM进行分析,大致效果如下:
这里选择“计算保留大小”。这个保留大小是递归计算实例之间的依赖,得到的总大小。因为去掉了循环依赖,所以并不完全准确,但是用于排查够了。选择保留大小最大的实例,一般就是罪魁祸首了!
最后排查出的结果,是公司的RPC中间件使用了ThreadLocal来保存一个context,但是最后却没有释放。按照架构组的说明,升级了版本,问题解决!
相关文章推荐
- 记一次线上故障的排查过程
- 又一次线上OOM排查经过
- 【原创】记一次线上Tomcat故障排查-struts2 “bug”导致tomcat阻塞
- 一次故障排查经过
- 一次线上tomcat应用请求阻塞的排查经过
- 一次线上OOM过程的排查
- 线上故障排查——drools规则引擎使用不当导致oom
- Java线上应用故障排查之二:高内存占用
- 线上应用故障排查之一:高CPU占用
- 线上应用故障排查之一:高CPU占用
- 记一次线上问题的排查过程
- 一次网络故障排查后的感慨
- 一次由于开机磁盘自检导致的启动故障排查
- 一次网络故障的排查
- 线上应用故障排查之一:高CPU占用
- 线上应用故障排查之一:高CPU占用
- 记一次故障经过
- 一次线上机器load负载过高报警问题排查及其后续处理
- 线上应用故障排查之一:高CPU占用