问题产生：

作者最近在搭建Hadoop+Hive集群时，将NameNode、DataNode、Rm全部部署到一台物理机上，查询量较大时连接挂掉。

问题定位：

使用JPS命令查看Metastore服务正常运行，hive2--Runjar挂掉。重启之后，过段时间又会挂掉。

Linux 内核有个机制叫OOM killer(Out Of Memory killer)，该机制会监控那些占用内存过大，尤其是瞬间占用内存很快的进程，然后防止内存耗尽而自动把该进程杀掉。内核检测到系统内存不足、挑选并杀掉某个进程的过程可以参考内核源代码linux/mm/oom_kill.c，当系统内存不足的时候，out_of_memory()被触发，然后调用select_bad_process()选择一个”bad”进程杀掉。如何判断和选择一个”bad进程呢？linux选择”bad”进程是通过调用oom_badness()，挑选的算法和想法都很简单很朴实：最bad的那个进程就是那个最占用内存的进程。

查看系统日志：

grep "Out of memory" /var/log/messages

问题分析：

hive2服务需要total-vm（进程使用的虚拟内存），anon-rss匿名内存（RAM实际分配的大小），file-rss映射到文件和设备的大小。

hive2服务生成mr程序，进行查询数据时，瞬间会占用大量内存。物理机的内存耗尽出发了系统的oom  killer导致。

问题解决：

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

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

当overcommit_memory=1 永远允许进程overcommit

当overcommit_memory=2 永远禁止overcommit

增大机器内存

服务部署分散到不同的机器上。