一次线上OOM过程的排查

一.出现问题

在前一段时间日常环境很不稳定，前端调用mtop接口会出网络异常或服务不存在的异常。查询了服务器上的HSF会有偶尔挂死的情况，服务器上的接口服务都不可用。于是我们对服务器上的状况进行了排查。

二.排查问题的过程

在这次的问题排查主要是围绕JVM的内存使用情况，生成对象分布情况以及GC情况来讨论的。中间有一些细节一开始存有疑问，迷雾的排除不算太顺利。首先要感谢下基础架构事业群的右席，井桐，梁希，坤谷 ，蚂蚁的寒泉子，中间技术部的思邪，望淘以及我们部的行默，今为，张霸，常晓师兄的一起讨论与问题排查的推动。为了写一篇比较干货，看了之后能立即上手开始排查一些类似问题的论文，我废话不多说，写一篇忽略掉曲折过程，直达终点的BLOG,有不当之处欢迎看官指出　:）

三.排查问题的步骤

1.查看服务器大概情况

首先最容易想到的是top命令，它能够实时显示系统中各个进程的资源占用状况，经常用来监控linux的系统状况，比如cpu、内存的使用。我上下当时截图的状况

由于前段时间服务不可用了，于是我们重启了ali-tomcat服务，发现Java进程重启之后最显著的问题就是占用内存挺多，虚拟内存总量占了5.5G+，43.2%。

2.查看Java进程突然不服务的原因

先查看过了一些业务日志与关系紧密的中间件，组件(比如HSF,Mtop等）的日志，无明显历史错误。于是我们在考虑Java进程突然不可用的原因。这里推荐一个很实用的命令:dmesg。dmesg可以用来查看开机之后的系统日志，其中可以捕捉到一些系统资源与进程的变化信息。dmesg |grep -E ‘kill|oom|out of memory’ 来搜索内存溢出的信息挺实用。我们这次