• <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 閱讀(2038) 評論(1)  編輯 收藏 引用 所屬分類: 游戲開發

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

            文章轉載請注明出處

            常用鏈接

            留言簿(11)

            隨筆分類

            隨筆檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            久久无码高潮喷水| 久久99热这里只频精品6| 久久精品国产亚洲AV无码娇色| 色婷婷狠狠久久综合五月| 国产成人久久精品二区三区| 久久久久久一区国产精品| 武侠古典久久婷婷狼人伊人| 亚洲午夜久久久影院| 91亚洲国产成人久久精品| 综合久久精品色| 青青草原综合久久| 久久精品国产亚洲AV影院| 精品久久久久久国产91| 久久伊人精品青青草原日本| 久久国产免费观看精品3| 久久WWW免费人成—看片| 久久人人爽爽爽人久久久| 免费一级做a爰片久久毛片潮| 久久久精品人妻一区二区三区蜜桃| 久久亚洲欧美日本精品| 日产精品久久久久久久| 久久久久亚洲AV无码去区首| 99久久免费国产精品热| 亚洲va久久久噜噜噜久久天堂| 久久久精品久久久久特色影视| 精品久久久久久久| 久久福利青草精品资源站免费| 综合网日日天干夜夜久久| 九九久久精品无码专区| 久久亚洲欧美日本精品| 国产亚洲精品自在久久| 国产亚洲美女精品久久久2020| 国产高潮久久免费观看| 久久99国产精品一区二区| 亚洲国产精品无码久久久蜜芽| 成人综合久久精品色婷婷| 久久精品一区二区影院| 久久精品国产亚洲沈樵| 女人香蕉久久**毛片精品| 精品久久久噜噜噜久久久| 久久综合给合久久国产免费|