问题产生：
作者最近在搭建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
增大机器内存
服务部署分散到不同的机器上。
标签：overcommit,OOM,killer,内存不足,bad,内存,memory,进程 From： https://www.cnblogs.com/yaoshuigebiss/p/17164143.html