引子
最近用機器人做NPC的壓力測試,突然發現一臺機器能支持的機器人數量劇減,而且運行一段時間后整臺機器直接內存耗光死機.經過觀察,發現1個機器人在運行一段時間之后內存能占用到120M之多,而且還在不斷增加,同時內存無法手動回收.
以前1個機器人大概消耗10M-20M的內存,這次的消耗明顯異常了,所以初步判斷邏輯上存在lua對象泄漏:在某些沒有注意到的地方長期引用著不再使用的lua對象,導致這些對象無法被gc.
為了解決這個問題,google到一篇相似問題的文章,lua內存泄漏查證.文章的大概思路就是:
- 資源跟蹤,定位哪些資源泄漏
- 引用檢索,查找泄漏的資源被哪個模塊引用
資源跟蹤
定義:將應用中分配的lua對象添加到一個弱表中.執行完整的gc后,還能從弱表中索引到的對象表示它還在別的地方被引用著,可能是正常的引用,也可能是一處內存泄漏.
我使用了一個弱鍵表,該表以要跟蹤的lua對象為鍵,該對象的描述信息為值.其中的描述信息包含了對象描述和對象創建時間兩項.對象描述用于區別不同的跟蹤對象;創建時間則用來在打印弱表的時候判斷對象的存活時間是否合理.
我定義的接口是:function TraceMem(obj, description);
雖然機器人可以動態的加載無盡的模塊,但是幾乎所有的資源都是由幾個基礎模塊開始分配的,所以添加對象跟蹤相對比較簡單.經過修改,運行,測試,從弱表中打印出來的數據發現,機器人中有大量的移動包和移動相關的計時器對象沒有被gc掉,這些對象多數都已經存活了100秒以上.場景中NPC都是僵尸,每個移動的時間應該在5秒以下,所以可判定這些移動對象是泄漏.
問題的范圍縮小了,但還是看不出哪段代碼造成了泄漏?泄漏的對象在哪一個模塊中被引用?
引用檢索
定義:從某個節點開始搜索所有該節點引用的對象以及遞歸搜索子節點,找到要搜索的對象,打印出引用路徑.
最常見的可以從_G開始搜索.搜索到的每個table,取其key和value遞歸搜索;搜索到的每個函數,取其upvalue遞歸搜索.至于是否需要搜索對象的環境表和metatable,以及全局registry表,則取決于具體需求.我因為用不上,就沒有搜索這一部分.
搜索的時候注意標記已經搜索過的節點,避免重復搜索.最好能縮小搜索范圍,而不是從_G開始搜索,另外應該能每次只搜索指定的部分引用而非全部,可以極大的縮短等待時間.搜索所有的引用其實相當耗時.
我定義的搜索接口是:function Search_r(obj, node, mark, result);
經過引用檢索處理后,我看到了計時器模塊引用了那些泄漏的移動包和移動計時器對象,這些對象的創建時間和引用他們的激活時間居然是相同的,這導致了這些計時器對象不會再激活,同時也失去了激活后釋放的機會,造成了內存泄漏.而根本原因,則是移動處理模塊在使用計時器的時候傳入了0超時參數,因為僵尸走得太慢了.
到此,問題就算全部解決了.
posted on 2010-08-14 15:41
LOGOS 閱讀(7025)
評論(2) 編輯 收藏 引用