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

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

            文章轉載請注明出處

            常用鏈接

            留言簿(11)

            隨筆分類

            隨筆檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            色播久久人人爽人人爽人人片AV| 亚洲精品99久久久久中文字幕| 久久一日本道色综合久久| 99久久99久久精品国产片果冻| 亚洲国产另类久久久精品黑人| 国内精品久久久久影院免费| 青青草原综合久久大伊人精品| 开心久久婷婷综合中文字幕| 亚洲AV无码成人网站久久精品大| 97久久精品人人澡人人爽| 无码八A片人妻少妇久久| 久久久久国产一级毛片高清版| 亚洲人AV永久一区二区三区久久| 久久99久久99精品免视看动漫| 久久青青草原精品国产不卡| 久久久噜噜噜www成人网| 亚洲美日韩Av中文字幕无码久久久妻妇 | 亚洲精品无码久久不卡| 国产精品久久久福利| 久久综合久久综合亚洲| 久久se这里只有精品| 久久久久四虎国产精品| 国内精品人妻无码久久久影院| 国产精品久久久久久久人人看| 国产精品亚洲综合专区片高清久久久| 色欲综合久久中文字幕网| 麻豆久久久9性大片| 青青草原综合久久大伊人导航 | 久久国产视屏| 久久综合狠狠色综合伊人| 久久99国内精品自在现线| 99久久精品免费看国产一区二区三区| 久久久久国产精品三级网| 久久久久久狠狠丁香| 99精品国产在热久久无毒不卡 | 国产精品VIDEOSSEX久久发布| 91精品国产乱码久久久久久| 精品熟女少妇av免费久久| 99久久99久久久精品齐齐| 99久久婷婷免费国产综合精品| 久久天天躁狠狠躁夜夜avapp|