記一次尷尬的Java應用記憶體洩露排查

摘要： 這星期被線上JVM記憶體佔用不斷增大的問題所困擾,自己提出了一些假設,然後去實施驗證都一一失敗了,有一些經驗和教訓在這裡分享下. 之所以是尷尬,是最後因為偶爾出現修復了另一個問題導致記憶體不再上升,但這之間的關係還未明瞭,還需要繼續追蹤. 這裡講述一下這次排查的過程. 直接記憶體的...

這星期被線上JVM記憶體佔用不斷增大的問題所困擾,自己提出了一些假設,然後去實施驗證都一一失敗了,有一些經驗和教訓在這裡分享下.

之所以是尷尬,是最後因為偶爾出現修復了另一個問題導致記憶體不再上升,但這之間的關係還未明瞭,還需要繼續追蹤.

這裡講述一下這次排查的過程.

直接記憶體的錯誤判斷

最開始考慮是直接記憶體的問題,觀察GC行為發現沒有發生過一次fgc,想當然覺得應該是直接記憶體無法回收,並且在手動執行gc之後記憶體佔用的確是下降的.

於是調整了一波JVM引數,將堆大小設定為2500M,並配置MaxDirectMemory用來觸發fgc.

但最後發現記憶體依舊增長,且還是沒有fgc.

再觀察了下heap(jmap -heap)的情況,發現手工觸發fgc後,heap釋放的大小和記憶體下降幾乎一致.

在使用JMX查看了direct pool(java.nio.BufferPool)後驚奇地發現..直接記憶體並沒有多少使用(我們底層用了netty,下意識認為出了問題):

圖中所示最大隻用了4M左右.

最後設定了 Xms 之後發現fgc已經沒有作用,記憶體的使用量不會再下降,排除掉了這個因素.

這個錯誤的判斷最主要的原因還是先入為主,沒有收集支撐的直接證據.

stack中的間隙

發現了一些有趣的東西,大量的64M塊.

直覺告訴我,快找出問題了.

搜尋了下發現類似的問題:

解決方法也很直接換一個分配記憶體的庫.

可選的也只有tcmalloc和jemalloc.

選擇了前者,配置之後效果出眾.

已經沒有上圖中那麼多的64M塊了.

並且啟動後的記憶體使用是掉了下來,但是好景不長.

看來問題不在這裡.

看似沒有關聯的問題

周常部署的時候出現一個問題,導致heap OOM,我跟了下發現了一段程式碼記憶體溢位,但看似和這個堆外記憶體引起的問題沒有關聯就沒怎麼在意.

第二天同事修復了這個問題,遷移走了這個介面到另一個服務.

tcmalloc的heap profiling無法使用,一開啟 libunwind 就 segment fault 退出,換成jemalloc後開啟.

還在想是不是常見的那個zip溢位的問題,但是搜尋了程式碼庫沒有發現忘記關閉的情況,等著看下增長和dump驗證下.

觀察了一會兒,突然發現記憶體不再增長了.

那坨profiling也失去了意義... ...

這就感覺非常尷尬了...

繼續追蹤

更尷尬的是另一個服務炸了... ...

繼續跟進,先把jemalloc配置過去,等下一次增長看下dump.

隨著時間的推移遇見了各種各樣的問題.

這次排查除了對之前積累的知識的運用,更多像是一次對搜尋引擎熟練度的提升 :( .

但過程還是很不錯的,也看到了一些自己以前沒有接觸過的知識.

深深感受到自己知識的匱乏,就像深淵(??)一樣,逐漸深入才會發現不一樣的風景.

生活中還是要多(xie)些bug才會更精彩的啊... ...

Line"/>

參考資料:

ofollow,noindex" target="_blank">http://lovestblog.cn/blog/2015/05/12/direct-buffer/

https://yq.aliyun.com/articles/227924

https://github.com/jeffgriffith/native-jvm-leaks