---
title: 實務中遇到OOM 的GO排查紀錄
---
# 實務中遇到OOM 的GO排查紀錄

###### tags: `Golang`

這天的Test3 環境一直呈現緩慢的狀態，整個系統最後都崩潰。 重啟會暫時恢復正常，沒多久又出現相同情況，於是有了今日的排查。

1. 找到大方向的問題： 在Linux execute "top", then press M to monitor system runtime, I founded 1 go application OOM, occupation memory 99%。 於是定位到go chat系統
2. 先在本機，透過go [pprof](https://hackmd.io/W2qHkgixRvO1rNIQ_J8LnA#二十四、效能分析-2-pprof) 這方便的go語言自帶工具，發現99%資源被MQ的library某行memory分配所佔用。 找到中顆粒度問題
3. 接著麻煩的是出問題的代碼並不是我們自己所寫的，一來無法修改，二來nat mq的library廣為使用，餵狗也沒有得到太多相同問題可以參考，基本可以定位到是我們對nats的使用必然存在什麼特殊的地方。 這裡雖然沒有具體找到解決方法，但也得到了一些線索。
4. 回想最近針對這系統的改變，想到一個應用上比較特殊的修改： 因為其他系統推送mq時遇到消息體大於nats 預設上限的1MB，因此我們進系統調整了nats配置文件，提高消息體上限到10MB。 於是我將訂閱該頻道的代碼註釋掉，再測試即發現系統恢復正常了。 因此找到了問題的源頭。
5. 回過頭請推送mq的消息上游檢視消息體內容，將消息做適度的切割，之後系統便恢復了正常。

這次排查過程也學習了很多。 也得到一個心得： 讓專人負責專門的系統是有必要的。專人才能更深度的掌握系統的細節、以及該系統最近的變化、遇到過的問題等等，都可以在某些時刻派上用場，更高效的定位問題、排除問題，或者提出有意義的訊息給大家集思廣益。