公司新上線一次，引發oom，增大記憶體，重啟。未發生，然後又重啟，一天之後又發生了。。根據上次上線的內容去挨個功能順藤摸瓜。發現了這個地方。
根據日誌,發現是oom的問題.從大的方面來講,主要採取了兩個步驟:
1.讓gc日誌跑起來,觀察到馬上進行fullgc之前,執行命令進行dump命令:
jmap -dump:format=b,file=./alertddump 430880..430880 是 alertd的pid..最後會生成乙份檔案,,該檔案的大小就是該後台設定的記憶體最大的大小.
2.將本分生成的檔案匯入到memoryanalyzer分析器裡面,選擇leak模式:會生成乙個分析的結果介面, 如下圖:
最後,定位到了出問題的那一行**.原因是svcrcagraph這個類和裡面持有的子類互相持有,導致在json序列化的時候,互相引用:大致**模型如下:
class svcrcagraph
class childnode
}]}
一次線上oom問題記錄
某天早上發現服務無法正常訪問，於是展開問題排查。1。首先檢視日誌，發現有oom日誌存在。這時候看到oom，犯了想當然的錯誤，認為是記憶體不足，堆記憶體空間已經用完。於是檢視 發現某個模組中有如下 誰寫的，站出來，我保證不打你。當時盲目的認為就是使用這個執行緒池的問題 關於此執行緒池的弊端不再贅述 於...
記一次 OOM 查詢過程
監控系統發現服務掛掉,登上機器ps ef grep 發現程序還在，因為監控系統是通過心跳檢測來監控服務的存活狀態的，服務假死 1 df free top 三連 磁碟空間正常 記憶體使用率正常 某個程序的cpu佔用率達300 多 2 top h p pid 檢視占用cpu最高的程序對應執行緒，得到執行...
記一次排查記憶體洩漏的過程
排查過程 程式測試執行過程中，其中乙個程序被linux系統給殺掉了，檢視系統日誌，發現是進行占用記憶體過大而觸發linux oom給殺掉了。重啟反覆幾次後均被殺掉，發現是記憶體洩漏問題。另發現有的時候有記憶體洩漏，有的時候沒有記憶體洩漏。針對這種情形，首先想到的是進行重現，然後使用工具檢測排查，同時...