oom排查

广告位

1.外在表现

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

2.辅助工具

(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+(cat /proc/uptime|cut -f 1 -d' ')+12288812.926194"|bc ​​ seconds"

3.排查过程

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

(1).jps -mlvV

找出当前java进程号1234,linux环境下可能要先执行

export JAVA_HOME=/*/*
export PATH=JAVAHOME/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
本文来自网络,不代表技术学习分享_CKX技术立场,转载请注明出处。

作者: CKX技术

上一篇
下一篇
广告位

发表回复

返回顶部