记一次linux内存使用率过高的核查经历

问题背景

有同事反映我们有个ETL服务器启动一些作业时报错，我看了下是内存溢出的问题。由于这台主机以前也出现过启动java作业时，报内存溢出错误，当时是因为主机ulimit设置较低的原因，并且我也已经给调大了很多。我第一反映是难道设置的值还是太小？

问题核查

top命令看一下机器现状

top

我这里是看一下机器状况，有时候内存使用率高可能也伴随着cpu使用率高。如果纯粹看内存使用情况，也可以用free命令。

当然这个是目前正常情况的截图。异常情况当时着力于解决问题，并没有截图。 我在top命令下看内存使用率时主要看以上4个指标：total（总共有多少内存），used（使用了多少内存），buffers(有多少内存是buffer占用)，cached（有多少内存是cached占用）。
真实的内存使用是userd - buffers -cached，所以当cached和buffers比较高时没有关系。我当时遇到的情况是userd很高（131G）,而buffers和cached加起来不过（5~6G），这种情况明显不是ulimit设置的问题。

如果内存使用率并不高，依然报内存溢出，可能是ulimit设置的问题，详见我另一篇博文java 启动失败 his_err_pid.log 内存溢出

既然内存使用率是真实过高，那么继续看一下是哪些程序内存占用较高。

top窗口内键入F，会显示选择排序字段（默认是cpu），键入n/N即可以调整为按内存使用率排序。
##ps : top窗口内键入h，会显示帮助信息

找到几个看似异常的TopN作业进程ID，用ps -ef|grep {pid}看一下是什么作业。我这里发现几个占用内存较高的几个java作业，有的占用1G-，有的占用1G+。并且这几个java程序也是我开发的（尴尬，自己埋雷了？）。于是一番搜索如何分析java程序是否有内存溢出，我后续是用的jmap以及MemoryAnalyzer

其实查问题以及如何解决问题的过程还是蛮曲折的，各种资料查阅了解。在下载MemoryAnalyzer工具的时候，可能是国外网站，下载超慢。想到以前也分析过一些java程序，于是在本机搜了下，居然真有下载过。看来好记性不如烂笔头，当时也没分析出个所以然，平常用的也不多，也就忘了，也是这次要记录一下的原因之一。

java程序内存使用分析

1 用jmap把java程序内存使用情况导出

#导出整个JVM 中内存信息
jmap -dump:format=b,file=文件名 [进程ID]

2 打开MemoryAnalyzer工具导入该文件
PS: 如果程序在你本机上运行，可以不用第一步操作。直接用"Acquire Heap Dump"即可。

3. 打开之后，会显示你的程序内存使用情况。
   PS:我的程序打开之后，Total只有1.6M，我的第一感觉是内存没有用很多呀。但是既然机器内存那么高，是不是我理解错了。其实也倒逼自己认识学习这个软件，继续…
   
   4 点击这个按钮，可以类实例资源情况。还可以借助帮边的工具按钮分组查看。
   

5 这个工具还有个好用的地方，就是对同一进程可以根据不同时间点的内存使用情况进行对比分析。比如内存正常时导出一个dump文件，内存异常时再导出一个dump文件。在该工具下打开多个dump文件时，工具会自动显示一个按钮。点击该按钮即可对比分析。

好啦，这个工具就写到这里啦。我这边各种对比之后，并没有发现我的程序有异常。然额，就当我当晚就要放弃继续查下去的时候，ps -ef打印看了下（之前都是ps -ef|grep “xxx”）。what fuck，居然有个程序挂起了n多，并且内存占用比较小，所以top也没发现。虽然小，但是多了也扛不住啊。

原因是因为有个crontab任务每天定时起一个java程序，但是这些程序并没有正常结束，一直僵着，成了僵尸进程。。。果断都kill掉，再看主机的内存使用情况，立马降下来，且正常了。

PS:说到避免crontab重复起任务，可以通过记录pid，生成一个隐藏标志文件，程序结束后删除。下次启动时，通过先检查是否存在标志文件来启停程序。另外也可以用ps -ef|grep “作业关键词”|grep -cv "grep"获取进程数量，来简单判断是否已有程序挂起。