最近我們為了節省開支，大資料集群下了幾個節點，結果沒執行兩天，就出現了掉節點的情況；
經排查，發現節點並沒有問題，可以正常登陸，排除節點、硬體故障；
去對應節點檢視datanode.out日誌，發現報錯資訊得知：節點掛掉原因是因為oom；
定位到hadoop-env.s**件中的hadoop_datanode_heapsize引數，現在我們集群的堆記憶體引數是3g，但是我們因為之前下了幾個節點，導致我們每個節點的塊數量有將近700萬塊；正常情況下，100萬塊對應1g左右的記憶體，我們這裡設定8g，預留出1g；
然後滾動重啟datanode，問題得到解決。
記一次線上OOM問題
首先是 jmap dump format b,file file.hprof 匯入mat工具 定位的問題是 standardmanager和standardsession檢視原始碼發現concurrenthashmap node就是standardmanager的session屬性 protecte...
記一次Orika導致的OOM
有乙個專案執行一段時間後就會出現oom，下面梳理下尋找問題根源的方法 某一天，乙個好久沒動過的服務崩掉了，top檢視程序占用cpu高達700 按照top，jstack一條龍查詢導致異常的執行緒 這裡沒看到什麼異常，把堆檔案dump到本地進行分析 看到hashmap將近佔了記憶體大小的50 開始尋找專...
記一次 OOM 查詢過程
監控系統發現服務掛掉,登上機器ps ef grep 發現程序還在，因為監控系統是通過心跳檢測來監控服務的存活狀態的，服務假死 1 df free top 三連 磁碟空間正常 記憶體使用率正常 某個程序的cpu佔用率達300 多 2 top h p pid 檢視占用cpu最高的程序對應執行緒，得到執行...