• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 119  文章 - 290  trackbacks - 0

            博客搬家了哦,請(qǐng)移步
            叫我abc

            常用鏈接

            留言簿(12)

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 305321
            • 排名 - 84

            最新評(píng)論

            閱讀排行榜

            引子

            最近用機(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)存泄漏查證.文章的大概思路就是:

            1. 資源跟蹤,定位哪些資源泄漏
            2. 引用檢索,查找泄漏的資源被哪個(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)榻┦叩锰?
            到此,問題就算全部解決了.

            PS:發(fā)現(xiàn)用html編輯blog非常不錯(cuò)啊,比cppblog自帶的所見即所得編輯器好用多了,還可以用CSS和插入一些有趣的js.

            posted on 2010-08-14 15:41 LOGOS 閱讀(7021) 評(píng)論(2)  編輯 收藏 引用

            FeedBack:
            # re: 檢測(cè)lua內(nèi)存泄漏 2010-08-15 22:55 tp
            有沒有直接定位監(jiān)測(cè)的啊?  回復(fù)  更多評(píng)論
              
            # re: 檢測(cè)lua內(nèi)存泄漏 2010-08-16 12:00 LOGOS
            @tp
            也有辦法
            你可以通過遍歷_G的方式記錄各個(gè)資源的生存狀況和引用路徑  回復(fù)  更多評(píng)論
              

            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            久久久亚洲欧洲日产国码是AV| 国内精品久久久久久久亚洲| 久久久久久久精品成人热色戒| 久久久久久精品无码人妻| 精品久久人妻av中文字幕| 久久亚洲综合色一区二区三区| 久久国产精品波多野结衣AV| 亚洲熟妇无码另类久久久| 亚洲国产精品久久| 亚洲综合日韩久久成人AV| 久久国产成人| 国产69精品久久久久777| 手机看片久久高清国产日韩| 国产高潮国产高潮久久久| 中文字幕无码久久精品青草| 亚洲国产精品久久久久婷婷老年| 久久综合亚洲色一区二区三区 | 国产精品成人久久久久三级午夜电影| 久久亚洲国产精品123区| 免费观看久久精彩视频| 中文字幕热久久久久久久| 久久影视综合亚洲| 久久综合久久久| www.久久热.com| 久久精品亚洲日本波多野结衣 | 青青草原综合久久| 狠狠色综合网站久久久久久久高清| 国产精品成人精品久久久| 18岁日韩内射颜射午夜久久成人| 99精品久久精品| 久久91亚洲人成电影网站| 色综合久久无码中文字幕| 久久亚洲AV成人无码软件| 亚洲国产精品成人久久蜜臀 | 蜜桃麻豆www久久| 久久99国产精品久久久 | 婷婷久久香蕉五月综合加勒比| 久久亚洲国产成人影院| 无码人妻久久一区二区三区蜜桃| 婷婷久久综合九色综合绿巨人| 欧美性大战久久久久久|