MAT發現導致OOM的具體功能表單的過程
背景
愚人節這一天公司專案出現了 大量FullGC的情況.
群裡發出來之後這邊進行了一些簡單的問題查詢.
堆區設定的事 30G 然後 dump檔案是 35G左右.
下載和解壓縮耗時 15min
使用40G堆區 全閃的Window虛擬機器進行解析
耗時 30分鐘.
最近自己眼神不是特別好使, 找東西總是很費勁
所以想總結一下, 方便後續進行類似的工作.
檔案情況說明
堆區設定的事30G大小
dump檔案為 33.8G
mat解析後所有檔案大小為 79GB
說明 堆外記憶體大約有4GB以上.
mat解析會昌盛大量的 index檔案. 是堆區大小的1.5 倍.
mat解析的整體情況
堆區設定是 30G 記憶體佔用是 26.5G左右.
一般情況下抓取dump會進行一次fullGC.
至少有一部分 FROM TO區域是空的
並且部分年輕代 也會倍清理, 所以一般不會到達 30G的巔峰數值.
點選齒輪檢視執行緒資訊
與一般的tracelog不同 mat分析會對每一個程序的 關聯記憶體進行對應
所以這個使用記憶體排序很快就可以知道是哪個執行緒的問題了.
左擊最大記憶體區域 list outgoing object
注意在overview區域是需要 左鍵單擊的
建議選擇 outgoing的 物件
這是就可以展示物件全貌了.
需要注意, 不要無限制的去點選最大的記憶體, 一般只需要在當前層次檢視就可以了
無限制的下一級是沒有意義的.
注意事項
String 物件可能是比較核心的部分, 如果是 % 分割
可以放到chrome 裡面會幫忙轉換成中文.
如果是 0x開頭的 可以 複製為 value
也會轉換為中文.
Oracle相關的會將 連線串給出來.
還有就是 業務程式碼相關的可以評判是哪個關鍵應用的功能異常.
查詢表單ID
根據這邊 丁楊老師的講解. 可以透過查詢 coyote 郊狼元件檢視到具體的 url
需要說明:
apache tomcat 是應用伺服器 coyote 郊狼是一個http 的工具鏈
裡面會有具體的url 可以找到對應的表單
所以在list outgoing object 裡面根據object name進行排序
查詢 <org.apache.coyote.Request> 類似的物件
可以在 <header> 物件進行 查詢.
一般會有多個物件 可以根據序號進行查詢, 會在7-12個序號之間 找到對應的url
注意選擇的 VALUEB的物件進行
