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