如何排查服務器的內存泄露

這篇文章主要介紹“如何排查服務器的內存泄露”，在日常操作中，相信很多人在如何排查服務器的內存泄露問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何排查服務器的內存泄露”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

• jps -l

• 查看虛擬機屬于哪個進程

• jstat -gcutil 20954 1000

• 新生代Eden區（E，表示Eden）使用了28.30%（最后）的空間，

• 兩個Survivor區（S0、S1，表示Survivor0、Survivor1）分別是0和8.93%，

• 老年代（O，表示Old）使用了87.33%。

• 程序運行以來共發生Minor GC（YGC，表示Young GC）101次，總耗時1.961秒，

• 發生Full GC（FGC，表示Full GC）7次，Full GC總耗時3.022秒，

• 總的耗時（GCT，表示GC Time）為4.983秒。

• 每1000毫秒查詢一次，一直查。

• gcutil的意思是已使用空間站總空間的百分比。

• 

• 查詢結果表明：這臺服務器的

• jmap -histo:live 20954

• 可以看出HashTable中的元素有5000多萬，占用內存大約1.5G的樣子。這肯定不正常。

• live 是可選參數，代表存活的對象

• 

• 紅線部分：

• MAT 分析工具

• Shortest Paths To the Accumulation Point表示GC root到內存消耗聚集點的最短路徑

• All Accumulated Objects by Class列舉了該對象所存儲的所有內容

• 為了找到內存泄露，我獲取了兩個堆轉儲文件，兩個文件獲取時間間隔是一天

• 

• 

• 對比兩個文件的對象，通過對比后的結果可以很方便定位內存泄露。

• MAT同時打開兩個堆轉儲文件，分別打開Histogram

• 在下圖中方框1按鈕用于對比兩個Histogram，對比后在方框2處選擇Group By package，然后對比各對象的變化

• 

• -64的意思是，倆文件中該對象比對，前者比后者少了64個

• 我內存泄露位置是一個list，這個list只在這里一直不停的往里添加eventInfo對象，卻沒有釋放過。

• 

• 從中找你熟悉的代碼

• 

• 

• 同時也會從首頁跳轉到Leak Suspects頁面

• 

• 

• 

• jmap -dump:format=b,file=<dumpfile.hprof> <pid>

• MemoryAnalyzer.ini文件

• Xmx參數，該參數表示最大內存占用量，默認為1024m

• jmap比較籠統，明顯的問題能檢查出來

• 補充jmap在線分析

• 修改MAT配置

• 從jmap獲取 .hprof 文件

• 選擇Leak Suspects Report, Finish就可以進入MAT分析頁面的首頁

• 在首頁上比較有用的是Histogram和Leak Suspects

• 點擊Leak Suspects會在堆轉儲文件同目錄內生成一個Leak Suspects.zip文件，

• 解壓該文件后可以通過瀏覽器打開分析結果

• Leak Suspects頁面

• 點擊Details進入詳情頁面

到此，關于“如何排查服務器的內存泄露”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！