|-转 生产出现oom（out of memory）问题，怎么排查？
ucloud上报工单，out of memory killed process 2480 （httpd），IT回复了这篇文章作为参考
https://www.cnblogs.com/c-xiaohai/p/12489336.html
1、使用dmesg命令查看系统日志
dmesg |grep -E ‘kill|oom|out of memory’，可以查看操作系统启动后的系统日志，这里就是查看跟内存溢出相关联的系统日志。
2、这时候，需要启动项目，使用ps命令查看进程
ps -aux|grep java命令查看一下你的java进程，就可以找到你的java进程的进程id。
3、接着使用top命令
top命令显示的结果列表中，会看到%MEM这一列，这里可以看到你的进程可能对内存的使用率特别高。以查看正在运行的进程和系统负载信息，包括cpu负载、内存使用、各个进程所占系统资源等。
4、使用jstat命令
用jstat -gcutil 20886 1000 10命令，就是用jstat工具，对指定java进程（20886就是进程id，通过ps -aux | grep java命令就能找到），按照指定间隔，看一下统计信息，这里会每隔一段时间显示一下，包括新生代的两个S0、s1区、Eden区，以及老年代的内存使用率，还有young gc以及full gc的次数。
使用 jstat -gcutil 8968 500 5 表示每500毫秒打印一次Java堆状况（各个区的容量、使用容量、gc时间等信息），打印5次
例如：
看到的东西类似下面那样：
S0 S1 E O YGC FGC
26.80 0.00 10.50 89.90 86 954
其实如果大家了解原理，应该知道，一般来说大量的对象涌入内存，结果始终不能回收，会出现的情况就是，快速撑满年轻代，然后young gc几次，根本回收不了什么对象，导致survivor区根本放不下，然后大量对象涌入老年代。老年代很快也满了，然后就频繁full gc，但是也回收不掉。
然后对象持续增加不就oom了，内存放不下了，爆了呗。
所以jstat先看一下基本情况，马上就能看出来，其实就是大量对象没法回收，一直在内存里占据着，然后就差不多内存快爆了。
5、使用jmap命令查看
执行jmap -histo pid可以打印出当前堆中所有每个类的实例数量和内存占用，如下，class name是每个类的类名（[B是byte类型，[C是char类型，[I是int类型），bytes是这个类的所有示例占用内存大小，instances是这个类的实例数量。
6、把当前堆内存的快照转储到dumpfile_jmap.hprof文件中，然后可以对内存快照进行分析
使用jmap -dump:format=b,file=文件名[pid]，就可以把指定java进程的堆内存快照搞到一个指定的文件里去，但是jmap -dump:format其实一般会比较慢一些，也可以用gcore工具来导出内存快照
例如：jmap -dump:format=b,file=D:/log/jvm/dumpfile_jmap.hprof20886
接着就是可以用MAT工具，或者是Eclipse MAT的内存分析插件，来对hprof文件进行分析，看看到底是哪个王八蛋对象太多了，导致内存溢出了
或者使用jdk的目录下的bin目录下的：jvisualvm.exe
8、总结：
一般常见的OOM，要么是短时间内涌入大量的对象，导致你的系统根本支持不住，此时你可以考虑优化代码，或者是加机器；要么是长时间来看，你的很多对象不用了但是还被引用，就是内存泄露了，你也是优化代码就好了；这就会导致大量的对象不断进入老年代，然后频繁full gc之后始终没法回收，就撑爆了...
