• <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)

            隨筆分類

            隨筆檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            久久久精品国产sm调教网站 | 久久久久久一区国产精品| AV色综合久久天堂AV色综合在| 欧美va久久久噜噜噜久久| 99久久久久| 亚洲国产精品久久电影欧美| 韩国无遮挡三级久久| 中文精品99久久国产| 国产精品美女久久久久| 午夜精品久久久久久影视777| 久久亚洲精品国产精品| 久久婷婷色香五月综合激情| 成人免费网站久久久| 狠狠色丁香婷婷久久综合五月| 99久久99这里只有免费费精品| 三级韩国一区久久二区综合| 国产91久久精品一区二区| 日韩欧美亚洲综合久久| 国产成人综合久久精品尤物| 久久午夜福利无码1000合集| 一本大道久久a久久精品综合| 亚洲精品国产美女久久久| 伊人久久亚洲综合影院| 精品乱码久久久久久夜夜嗨| 久久精品国产99国产精品澳门| 香蕉久久影院| 久久精品成人影院| 99久久亚洲综合精品网站| 一本色道久久88精品综合| 亚洲国产日韩欧美久久| 久久午夜福利电影| 国产福利电影一区二区三区,免费久久久久久久精 | 精品久久久久久| 久久天天躁狠狠躁夜夜躁2O2O| 久久人人爽人人人人爽AV| 污污内射久久一区二区欧美日韩 | 久久一区二区三区免费| 久久国产热这里只有精品| 久久免费大片| 少妇无套内谢久久久久| 精品久久久中文字幕人妻|