問題產生： 作者最近在搭建Hadoop+Hive集群時，將NameNode、DataNode、Rm全部部署到一臺物理機上，查詢量較大時連接掛掉。 問題定位： 使用JPS命令查看Metastore服務正常運行，hive2--Runjar掛掉。重啟之後，過段時間又會掛掉。 Linux 內核有個機制叫OO ...
問題產生：
作者最近在搭建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導致。
問題解決：
當overcommit_memory=0 允許進程輕微過量使用記憶體，但對於大量過載請求則不允許(預設）
當overcommit_memory=1 永遠允許進程overcommit
當overcommit_memory=2 永遠禁止overcommit
增大機器記憶體
服務部署分散到不同的機器上。
