• <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>
            posts - 14,  comments - 57,  trackbacks - 0

             問題

               最近游戲開始技術封測了,不過剛剛上線3個小時,Server就掛了,掛在框架代碼里,一個不可能掛的地方。
            從CallStack看,是在獲取數據時發送請求包的時候掛的,由于框架部分是其他部門的同事開發的,所以查問題的時候就拉上他們了,
            大家折騰了2天,沒有實質性的進展,服務器還是基本上每3個小時宕機一次。由于上層邏輯大部分都在我那,所以壓力比較大,宕機的直接原因是hashtable的一個桶的指針異常,
            這個hashtable是框架代碼的一個內部成員,按道理我們是無從破壞的,只有可能是多線程環境下迭代器損壞導致的。
            但是框架代碼在這個地方確實無懈可擊,所以真正的原因應該還是上層代碼破壞了堆內存,很可能是一個memcpy越界導致的。這畢竟是個猜想,如何找到證據呢,這是個問題。
            把所有代碼里的memcpy瀏覽了一遍,沒有發現明顯問題。

            猜測

              一般游戲中比較容易出現但是不好查的問題很多時候都是腳本(lua)導致的,我們的腳本部分是一個同事幾年前寫的,在幾個產品中都使用過,按道理沒這么脆弱,不過老大還是和最初開發這個模塊的部門溝通了下,
            還真發現問題了,趕緊拿了新的版本更新上去。經過一天的觀察,服務器沒有宕機了,OK,問題碰巧解決了,背了這么久的黑鍋,終于放下來了。

            PageHeap

               假如沒有碰巧解決了這個問題,正常的思路該如何解決這個問題呢,這個時候我懷念windows了,在windows下有PageHeap來解決這類寫越界的問題。基本思路就是每次分配內存的時候,都將內存的結尾放在頁的邊緣,緊接著這塊內存分配一塊不能寫的內存,這樣,一旦寫越界,就會寫異常,導致宕機。linux下沒有現成的工具,但是linux提供了mmap功能,我們可以自己實現這樣一個功能,當然,這一切都不用自己動手了,tcmalloc已經包含了
            這個功能了,不過在文檔里基本沒有介紹,我也是在閱讀tcmalloc代碼時看到的,這個功能默認是關閉的,打開這個開關需要改寫代碼:

            這個代碼在debugallocation.cc里:

            DEFINE_bool(malloc_page_fence,
                        EnvToBool("TCMALLOC_PAGE_FENCE", false),
                        "Enables putting of memory allocations at page boundaries "
                        "with a guard page following the allocation (to catch buffer "
                        "overruns right when they happen).");
            把false改成true就可以了。
            想要在項目里加入PageHeap功能,只需要鏈接的時候加上 -ltcmalloc_debug即可。把它加入項目中,試著運行下,直接掛了,
            仔細一看,原來是項目中很多成員變量沒有初始化導致的,tcmalloc_debug會自動將new 和malloc出來的內存初始化為指定值,這樣,一旦變量沒有初始化,很容易就暴露了。
            修改完這個問題后,編譯,再運行,還是掛,這個是mprotect的時候掛的,錯誤是內存不夠,這怎么可能呢,其實是達到了資源限制了。
            echo 128000 > /proc/sys/vm/max_map_count
            把map數量限制加大,再運行,OK了!
             
              但是游戲Server啟動后,發現一個問題,CPU長期處于100%,導致登陸一個玩家都很困難,gdb中斷后,info thread,發現大部分的操作都在mmap和mprotect,最開始
            懷疑我的linux版本有問題,導致這2個AP慢,寫了測試程序試了下,發現其實API不慢,估計是頻繁調用導致的。
            所以得換種思路優化下才可以,其實大部分情況下,我們free的時候,無需將頁面munmap掉,可以先cache進來,下次分配的時候,如果有,直接拿來用就可以了。
            最簡單的cache算法就是定義一個void* s_pageCache[50000]數組,頁面數相同的內存組成一個鏈表,掛在一個數組項下,這個很像STL的小內存處理,我們可以將mmap出來的內存的
            前面幾個字節(一個指針大小)用于索引下一個freePage。當然這個過程需要加鎖,不能用pthread的鎖(因為他們會調用malloc等內存分配函數),必須用spinlock,從linux源碼里直接抄一個過來即可。
            static void*   s_pagePool[MAX_PAGE_ALLOC]={0};

            malloc的時候,先從pagePool里面獲取:
            // 先從pagePool找
             void* pFreePage = NULL;
             spin_lock(&s_pageHeapLock);
             assert(nPageNum < MAX_PAGE_ALLOC);
             if(s_pagePool[nPageNum])
             {
               pFreePage = s_pagePool[nPageNum];
               void* pNextFreePage = *((void**)pFreePage);
               s_pagePool[nPageNum] = pNextFreePage;
             }
             spin_unlock(&s_pageHeapLock);

            free內存的時候,直接放到pagePoll里:
            spin_lock(&s_pageHeapLock);
             assert(nPageNum < MAX_PAGE_ALLOC);
             void* pNextFree = s_pagePool[nPageNum];
             *(void**)pAddress = pNextFree;
             s_pagePool[nPageNum] = pAddress;
             
             spin_unlock(&s_pageHeapLock);

            編譯、運行,OK了,CPU迅速降下來了,空載的時候不到1%,而且也能達到檢測寫溢出的問題。

            posted on 2011-05-14 21:16 feixuwu 閱讀(2034) 評論(1)  編輯 收藏 引用 所屬分類: 游戲開發

            FeedBack:
            # re: linux下PageHeap
            2014-06-20 16:25 | thinkstream
            博主經驗好豐富,現在過了3年了。看前輩的文章,抽絲剝繭。正好昨天發現page heap不知道為什么?謝了。  回復  更多評論
              
            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            文章轉載請注明出處

            常用鏈接

            留言簿(11)

            隨筆分類

            隨筆檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            国产精品伊人久久伊人电影| 免费精品国产日韩热久久| 人妻精品久久久久中文字幕| 久久精品一区二区影院| 久久久久久精品久久久久| 色偷偷偷久久伊人大杳蕉| 久久99国产精品久久99| 色悠久久久久久久综合网| 精品综合久久久久久888蜜芽| 久久久久中文字幕| 思思久久精品在热线热| 精品免费tv久久久久久久| 思思久久好好热精品国产| 久久99精品久久久久久| 2020国产成人久久精品| 狠狠色丁香婷婷综合久久来来去| 久久久久亚洲AV成人网人人网站| 久久精品国产亚洲AV高清热 | 久久婷婷色综合一区二区| 久久国产精品99精品国产| 合区精品久久久中文字幕一区| 久久99国产精品久久99果冻传媒| 亚洲婷婷国产精品电影人久久| 久久久久四虎国产精品| 久久亚洲精品人成综合网| 久久国产香蕉一区精品| 国内精品久久久久久久97牛牛| 久久亚洲中文字幕精品一区| 久久久精品国产亚洲成人满18免费网站| 无码国产69精品久久久久网站| 伊人久久大香线蕉综合网站| 中文字幕亚洲综合久久2| 日本福利片国产午夜久久| 久久久精品人妻一区二区三区蜜桃| 2019久久久高清456| 怡红院日本一道日本久久 | 色综合久久最新中文字幕| 亚洲AV无码久久精品蜜桃| 国产毛片欧美毛片久久久| 久久人人爽人人爽人人片AV高清 | 99久久99久久精品免费看蜜桃|