一.背景描述

     大早上突然同事给我打电话，说我的服务调不通了，我上了服务器看了一下，果然我的服务不见了，瞬间感觉心中有一万只草尼马奔腾而过。。。。

二.开始调查原因

   1.打开日志果然停留在早上6:20左右，之后再也没有任何输出了（因为发生公司生产环境，不方便贴出图片）使用大家都经常用的命令tail -f 查看即可。

   2.问下运维同事有没有挂掉之前的线程号，很遗憾并没有，使用dmesg | grep java命令， 看看是否存在被杀的相关信息，还真发现了不少进程被杀的情况，随后一个被杀的进程是：12729。抱着试试心态，看看在启动日志中能不能找到一点蛛丝马迹，果然启动信息中有启动线程号（因为发生公司生产环境，不方便贴出图片），以后想要在就可以先找到进程号，

(1)dmesg：dmesg | grep 12729 

(2)message日志： tail -10 /var/log/message

从上面的时间来看，就正好吻合了。

三.定位问题

打开集群中同一以应用内存占用的情况，大约占用在16%-17%之间，而挂掉的那台服务器上内存明显不足，百度下oom-killer映入眼帘

OOM-Killer

操作系统(operating system)构建在进程(process)的基础上. 进程由内核作业(kernel jobs)进行调度和维护, 其中有一个内核作业称为 “Out of memory killer(OOM终结者)”, 与本节所讲的 OutOfMemoryError 有关。

Out of memory killer 在可用内存极低的情况下会杀死某些进程。只要达到触发条件就会激活, 选中某个进程并杀掉。 通常采用启发式算法, 对所有进程计算评分(heuristics scoring), 得分最低的进程将被 kill 掉。因此 Out of memory: Kill process or sacrifice child 是系统内核内置的一种安全保护措施。

值得注意的是，有些时候 free -m 时还有剩余内存，但还是会触发OOM-killer，可能是因为进程占用了特殊内存地址

平时我们应该留意下新进来的进程内存使用量，免得系统重要的业务进程被无辜牵连

可用 top M 查看最消耗内存的进程，但也不是进程一超过就会触发oom_killer

参数/proc/sys/vm/overcommit_memory可以控制进程对内存过量使用的应对策略

（1）当overcommit_memory=0 允许进程轻微过量使用内存，但对于大量过载请求则不允许

（2）当overcommit_memory=1 永远允许进程overcommit

（3）当overcommit_memory=2 永远禁止overcommit

我们系统正是使用的默认值0

从上图的红框中可以看到，在bms-service挂掉之前，可用内存确实存在下降趋势，至此问题找到。

四.解决方案

1、将应用迁移至内存富裕的机器节点

2、减少和控制内存的使用