一次OOM排查过程

一、外在表现

前段时间系统经常出现OOM，服务很不稳定，偶尔会有java进程不存在的情况，临时解决方案只能是重启。

 

二、辅助工具

1.top

用top查看，发现内存占用(%MEM)挺多，其他指标均正常。

 

2.dmesg

如果发现自己的java进程突然消失了，那么就要借助dmesg来查看开机之后的系统日志

命令为dmesg | grep -i 'kill'或者搜索oom(out of memory),如果能搜索到相关信息，则说明java进程是被操作系统kill了，操作系统有一种机制，它会在机器的内存耗尽前，挑选几个占用内存较大的进程杀死(实际也是有一定的计算规则)，通常被杀死的就是java进程，那么接下来就是看看是什么原因造成内存这么大。dmesg 输出的格式不易查看，可以通过命令进行转换。date -d "1970-01-01 UTC `echo "$(date +%s)-$(cat /proc/uptime|cut -f 1 -d' ')+12288812.926194"|bc ` seconds"

 

三、排查过程

OOM的原因一般为内存泄露，创建了对象不能释放，也有可能是突然间创建了大对象，有时加载过多的class也是原因。线上遇到OOM需要做两件事情第一个是dump内存，第二个是看下GC日志。

 

1. jps -mlvV （或者 ps -ef | grep java）

找出当前java进程号1234

linux环境下可能要先执行

export JAVA_HOME=/*/*

export PATH=$JAVA_HOME/bin:$PATH

 

2. jstat -gcutil 1234 1000 10

从这一步查出，full gc次数频繁，由此可见原因是老年代空间不足

 

3. dump内存

接下来就是排查问题最重要的一步，dump内存最容易想到的是

jmap -dump:format=b,file=heap.hprof 1234。

注意如果用jmap来dump的话，一来非常慢，二来可能会出异常，在linux JDK1.6某个版本里使用jmap可能会让系统挂掉，可以通过-d64来解决(jmap -J-d64 -dump:format=b,file=dump.bin PID)。而jdk7的某个版本则会抛出异常，这是jdk的bug.

一般dump下来的内存有几个G，而有时候dump下来只有一两百兆，说明jmap有问题，需要多执行几次jmap -dump才能得出正常结果，这个时候可以选用
gcore 把整个内存dump出来，然后再使用jmap把core dump转换成heap dump。

做法就是用gcore 1234命令来生成c版的core文件，再用命令jmap -dump:format=b,file=heap.hprof /bin/java core.1234.

 

4. 使用eclipse MAT或者visaul VM查看dump文件分析原因

在用eclipse分析dump文件时有可能因为文件过大而报异常，这时要调大eclipse本身占用的堆内存大小，在eclipse.ini文件里面，因为eclipse本身也是一个java程序。

通过自动dump下来的内存文件很快发现有一个对象占用内存非常大，解决后系统恢复正常。

 

5. 查看gc日志

排查OOM通常要结合tomcat的日志、gc日志来查看。如果没有任何JVM参数设置，gc日志默认打印在stdout.log文件里，里面可能会打其他的日志，而且GC日志也不会输出时间，所以在JVM启动参数里最好加以下命令，规范下GC日志输出到/home/admin/logs/gc.log，并且打印GC时间。

-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=/home/admin/logs

-Xloggc:/home/admin/logs/gc.log

-XX:+PrintGCDetails

-XX:+PrintGCDateStamps