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

            CppExplore

            一切像霧像雨又像風(fēng)

              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              29 隨筆 :: 0 文章 :: 280 評論 :: 0 Trackbacks

            作者:CppExplore 網(wǎng)址:http://www.shnenglu.com/CppExplore/
            服務(wù)器設(shè)計人員在一段時間的摸索后,都會發(fā)現(xiàn):服務(wù)器性能的關(guān)鍵在于內(nèi)存。從收包到解析,到消息內(nèi)存的申請,到session結(jié)構(gòu)內(nèi)存的申請都要小心處理,盡量減少內(nèi)存數(shù)據(jù)copy,減少內(nèi)存動態(tài)申請,減少內(nèi)存檢索。為達(dá)到這個目的,不同的地方有不同的方法,比如常見的包解析,使用緩沖區(qū)偏移以及長度來標(biāo)識包內(nèi)字段信息;內(nèi)存使用量固定的系統(tǒng),系統(tǒng)啟動就申請好所有需要的內(nèi)存,初始化好,等待使用的時候直接使用;基于license控制的系統(tǒng),根據(jù)license的數(shù)量,一次性申請固定數(shù)量內(nèi)存等......。本文不再總結(jié)這些特性方案,重點(diǎn)說下常見的通用的內(nèi)存池緩存技術(shù)。
                內(nèi)存池可有效降低動態(tài)申請內(nèi)存的次數(shù),減少與內(nèi)核態(tài)的交互,提升系統(tǒng)性能,減少內(nèi)存碎片,增加內(nèi)存空間使用率,避免內(nèi)存泄漏的可能性,這么多的優(yōu)點(diǎn),沒有理由不在系統(tǒng)中使用該技術(shù)。
            為了給內(nèi)存池技術(shù)尋找基石,先從低層的內(nèi)存管理看起。
            硬件層略掉不談,可回顧《操作系統(tǒng)》。
            一、linux內(nèi)存管理策略
                linux低層采用三層結(jié)構(gòu),實際使用中可以方便映射到兩層或者三層結(jié)構(gòu),以適用不同的硬件結(jié)構(gòu)。最下層的申請內(nèi)存函數(shù)get_free_page。之上有三種類型的內(nèi)存分配函數(shù)
            (1)kmalloc類型。內(nèi)核進(jìn)程使用,基于slab技術(shù),用于管理小于內(nèi)存頁的內(nèi)存申請。思想出發(fā)點(diǎn)和應(yīng)用層面的內(nèi)存緩沖池同出一轍。但它針對內(nèi)核結(jié)構(gòu),特別處理,應(yīng)用場景固定,不考慮釋放。不再深入探討。
            (2)vmalloc類型。內(nèi)核進(jìn)程使用。用于申請不連續(xù)內(nèi)存。
            (3)brk/mmap類型。用戶進(jìn)程使用。malloc/free實現(xiàn)的基礎(chǔ)。
            有關(guān)詳細(xì)內(nèi)容,推薦http://www.kerneltravel.net/journal/v/mem.htmhttp://www.kerneltravel.net上有不少內(nèi)核相關(guān)知識。
            二、malloc系統(tǒng)的內(nèi)存管理策略
                malloc系統(tǒng)有自己的內(nèi)存池管理策略,malloc的時候,檢測池中是否有足夠內(nèi)存,有則直接分配,無則從內(nèi)存中調(diào)用brk/mmap函數(shù)分配,一般小于等于128k(可設(shè)置)的內(nèi)存,使用brk函數(shù),此時堆向上(有人有的硬件或系統(tǒng)向下)增長,大于128k的內(nèi)存使用mmap函數(shù)申請,此時堆的位置任意,無固定增長方向。free的時候,檢測標(biāo)記是否是mmap申請,是則調(diào)用unmmap歸還給操作系統(tǒng),非則檢測堆頂是否有大于128k的空間,有則通過brk歸還給操作系統(tǒng),無則標(biāo)記未使用,仍在glibc的管理下。glibc為申請的內(nèi)存存儲多余的結(jié)構(gòu)用于管理,因此即使是malloc(0),也會申請出內(nèi)存(一般16字節(jié),依賴于malloc的實現(xiàn)方式),在應(yīng)用程序?qū)用妫琺alloc(0)申請出的內(nèi)存大小是0,因為malloc返回的時候在實際的內(nèi)存地址上加了16個字節(jié)偏移,而c99標(biāo)準(zhǔn)則規(guī)定malloc(0)的返回行為未定義。除了內(nèi)存塊頭域,malloc系統(tǒng)還有紅黑樹結(jié)構(gòu)保存內(nèi)存塊信息,不同的實現(xiàn)又有不同的分配策略。頻繁直接調(diào)用malloc,會增加內(nèi)存碎片,增加和內(nèi)核態(tài)交互的可能性,降低系統(tǒng)性能。linux下的glibc多為Doug Lea實現(xiàn),有興趣的可以去baidu、google。
            三、應(yīng)用層面的內(nèi)存池管理
                跳過malloc,直接基于brk/mmap實現(xiàn)內(nèi)存池,原理上是可行的,但實際中這種實現(xiàn)要追逐內(nèi)核函數(shù)的升級,增加了維護(hù)成本,另增加了移植性的困難,據(jù)說squid的內(nèi)存池是基于brk的,本人尚未閱讀squid源碼(了解磁盤緩存的最佳代碼,以后再詳細(xì)閱讀),不敢妄言。本文后面的討論的內(nèi)存池都是基于malloc(或者new)實現(xiàn)。我們可以將內(nèi)存池的實現(xiàn)分兩個類別來討論。
            1、不定長內(nèi)存池。典型的實現(xiàn)有apr_pool、obstack。優(yōu)點(diǎn)是不需要為不同的數(shù)據(jù)類型創(chuàng)建不同的內(nèi)存池,缺點(diǎn)是造成分配出的內(nèi)存不能回收到池中。這是由于這種方案以session為粒度,以業(yè)務(wù)處理的層次性為設(shè)計基礎(chǔ)。
            (1)apr_pool。apr全稱Apache portable Run-time libraries,Apache可移植運(yùn)行庫。可以從http://www.apache.org/網(wǎng)站上下載到。apache以高性能、穩(wěn)定性著稱,它所有模塊的內(nèi)存申請都由內(nèi)存池模塊apr_pool實現(xiàn)。有關(guān)apr_pool結(jié)構(gòu)、實現(xiàn)的原理,http://blog.csdn.net/tingya/(apache源碼分析類別中的apache內(nèi)存池實現(xiàn)內(nèi)幕系列)已經(jīng)有了詳細(xì)的講解,結(jié)合自己下載的源碼,已經(jīng)足夠了。本人并不推薦去看這個blog和去看詳細(xì)的代碼數(shù)據(jù)結(jié)構(gòu)以及邏輯。明白apr_pool實現(xiàn)的原理,知道如何使用就足夠了。深入細(xì)節(jié)只能是浪費(fèi)腦細(xì)胞,當(dāng)然完全憑個人興趣愛好了。
                這里舉例說下簡單的使用:

            #include "apr_pools.h"
            #include 
            <stdio.h>
            #include 
            <new>

            int main()
            {
                apr_pool_t 
            *root;
                apr_pool_initialize();
            //初始化全局分配子(allocator),并為它設(shè)置mutext,以用于多線程環(huán)境,初始化全局池,指定全局分配

            子的owner是全局池
                apr_pool_create(
            &root,NULL);//創(chuàng)建根池(默認(rèn)父池是全局池),根池生命期為進(jìn)程生存期。分配子默認(rèn)為全局分配子
                {
                    apr_pool_t 
            *child;
                    apr_pool_create(
            &child,root);//創(chuàng)建子池,指定父池為root。分配子默認(rèn)為父池分配子
                    void *pBuff=apr_palloc(child,sizeof(int));//從子池分配內(nèi)存
                    int *pInt=new (pBuff)  int(5);//隨便舉例下基于已分配內(nèi)存后,面向?qū)ο髽?gòu)造函數(shù)的調(diào)用。
                    printf("pInt=%d\n",*pInt);
                    
            {
                        apr_pool_t 
            *grandson;
                        apr_pool_create(
            &grandson,root);
                        
            void *pBuff2=apr_palloc(grandson,sizeof(int));
                        
            int *pInt2=new (pBuff2)  int(15);
                        printf(
            "pInt2=%d\n",*pInt2);    

                        apr_pool_destroy(grandson);
                    }

                    apr_pool_destroy(child);
            //釋放子池,將內(nèi)存歸還給分配子
                }

                apr_pool_destroy(root);
            //釋放父池,
                apr_pool_terminate();//釋放全局池,釋放全局allocator,將內(nèi)存歸還給系統(tǒng)
                return 1;
            }

                apr_pool中主要有3個對象,allocator、pool、block。pool從allocator申請內(nèi)存,pool銷毀的時候把內(nèi)存歸還allocator,allocator銷毀的時候把內(nèi)存歸還給系統(tǒng),allocator有一個owner成員,是一個pool對象,allocator的owner銷毀的時候,allocator被銷毀。在apr_pool中并無block這個單詞出現(xiàn),這里大家可以把從pool從申請的內(nèi)存稱為block,使用apr_palloc申請block,block只能被申請,沒有釋放函數(shù),只能等pool銷毀的時候才能把內(nèi)存歸還給allocator,用于allocator以后的pool再次申請。
                我給的例子中并沒有出現(xiàn)創(chuàng)建allocator的函數(shù),而是使用的默認(rèn)全局allocator。apr_pool提供了一系列函數(shù)操作allocator,可以自己調(diào)用這些函數(shù):
            apr_allocator_create
            apr_allocator_destroy
            apr_allocator_alloc
            apr_allocator_free
            創(chuàng)建銷毀allocator
            apr_allocator_owner_set
            apr_allocator_owner_get
            設(shè)置獲取owner
            apr_allocator_max_free_set 設(shè)置pool銷毀的時候內(nèi)存是否直接歸還到操作系統(tǒng)的閾值
            apr_allocator_mutex_set
            apr_allocator_mutex_get
            設(shè)置獲取mutex,用于多線程

            另外還有設(shè)置清理函數(shù)啊等等,不說了。自己去看include里的頭文件好了:apr_pool.h和apr_allocator.h兩個。源碼.c文件里,APR_DECLARE宏聲明的函數(shù)即是暴露給外部使用的函數(shù)。大家也可以仿造Loki(后文將介紹Loki)寫個頂層類重載operator new操作子,其中調(diào)用apr_palloc,使用到的數(shù)據(jù)結(jié)構(gòu)繼承該類,則自動從pool中申請內(nèi)存,如要完善的地方很多,自行去研究吧。
                可以看出來apr_pool的一個大缺點(diǎn)就是從池中申請的內(nèi)存不能歸還給內(nèi)存池,只能等pool銷毀的時候才能歸還。為了彌補(bǔ)這個缺點(diǎn),apr_pool的實際使用中,可以申請擁有不同生命周期的內(nèi)存池(類似與上面的例子程序中不同的大括號代表不同的生命周期,實際中,盡可以把大括號中的內(nèi)容想象成不同的線程中的......),以便盡可能快的回收不再使用的內(nèi)存。實際中apache也是這么做的。因此apr_pool比較適合用于內(nèi)存使用的生命期有明顯層次的情況。
                至于擔(dān)心allocator中的內(nèi)存一旦申請就再也不歸還給操作系統(tǒng)(當(dāng)然最后進(jìn)程退出的時候你可以調(diào)用銷毀allocator歸還,實際中網(wǎng)絡(luò)服務(wù)程序都是一直運(yùn)行的,找不到銷毀的時機(jī))的問題,就是杞人憂天了,如果在某一時刻,系統(tǒng)占用的內(nèi)存達(dá)到頂峰,意味著以后還會有這種情況。是否能接受這個解釋,就看個人的看法和系統(tǒng)的業(yè)務(wù)需求了,不能接受,就使用其它的內(nèi)存池。個人覺得apr_pool還是很不錯的,很多服務(wù)系統(tǒng)的應(yīng)用場景都適用。
            (2)obstack。glibc自帶的內(nèi)存池。原理與apr_pool相同。詳細(xì)使用文檔可以參閱
            http://www.gnu.org/software/libc/manual/html_node/Obstacks.html。推薦apr_pool,這個就不再多說了。
            (3)AutoFreeAlloc。許式偉的專欄http://blog.csdn.net/xushiweizh/category/265099.aspx
                這個內(nèi)存池我不看好。這個也屬于一個變長的內(nèi)存池,內(nèi)存申請類似與apr_pool的pool/block層面,一次申請大內(nèi)存作為pool,用于block的申請,同樣block不回收,等pool銷毀的時候直接歸還給操作系統(tǒng)。這個內(nèi)存池的方案,有apr_pool中block不能回收到pool的缺點(diǎn),沒有pool回收到allocator,以供下次繼續(xù)使用的優(yōu)點(diǎn),不支持多線程。適合于單線程,集中使用內(nèi)存的場景,意義不是很大。

            posted on 2008-02-18 16:55 cppexplore 閱讀(15061) 評論(17)  編輯 收藏 引用

            評論

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理 2008-02-18 17:29 CornerZhang
            謝謝!看來這個apr_pool不錯.  回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理 2008-02-18 18:39 eXile
            對于最后一個AutoFreeAlloc, 我碰巧也研究過, 其實對于你說的"沒有pool回收到allocator,以供下次繼續(xù)使用"的問題,它最近的實現(xiàn)中已經(jīng)解決了.
            在c++ 標(biāo)準(zhǔn)庫實現(xiàn)SGI STL中還有一種內(nèi)存池的實現(xiàn), 就是用一系列固定長的內(nèi)存池來實現(xiàn)一個不定長的內(nèi)存池, 它曾經(jīng)是gcc3中stl的默認(rèn)實現(xiàn), 但在gcc4中不再使用, 理由是在多線程情況下優(yōu)化并不明顯, 線程鎖反而成為瓶頸. 所以有時候一個線程一個內(nèi)存池也是一個選擇.
              回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理[未登錄] 2008-02-18 20:11 CppExplore
            @CornerZhang
            呵呵,apache很成功,apr_pool自然不會差。

            @eXile
            AutoFreeAlloc的發(fā)展方向應(yīng)該就是apr_pool。apr_pool已經(jīng)把變長的內(nèi)存池發(fā)展到極致,當(dāng)然這是當(dāng)前看到的,或許以后有內(nèi)存池會把變長內(nèi)存池推到一個新的高度。:)
            支持多線程的內(nèi)存池都是從單線程加鎖機(jī)制實現(xiàn)的,都提供無鎖的實現(xiàn)。apr_pool也是,顯式構(gòu)造allocator后不調(diào)用apr_allocator_mutex_set就是無鎖的實現(xiàn)。
            后面的boost和loki的無鎖和有鎖的實現(xiàn)區(qū)別更是明顯。   回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理 2008-02-19 12:33 空明流轉(zhuǎn)
            多線程的池子Lock-Free的解決辦法很有前途。原子操作速度很快,沒有鎖的消耗。  回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理[未登錄] 2008-02-19 15:59 cppexplore
            @空明流轉(zhuǎn)
            這個現(xiàn)在還是只能停留在美好的展望階段,不過這一天的到來不遠(yuǎn)了。
              回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理(一) 2008-02-19 21:49 空明流轉(zhuǎn)
            展望已經(jīng)不是展望了。就是庫中用的很少,但是不排除一些服務(wù)器上已經(jīng)用了這個玩意了。  回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理(一) 2008-03-19 16:43 xushiwei
            關(guān)于AutoFreeAlloc,推薦博主看一下以下兩篇:

            http://cpp.winxgui.com/cn:a-general-gc-allocator-scopealloc
            http://cpp.winxgui.com/cn:lock-free-gc-allocator
              回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理(一) 2008-03-19 16:45 xushiwei
            另外,AutoFreeAlloc與apr pools的性能對比:
            http://cpp.winxgui.com/cn:gc-allocators-vs-apr-pools  回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理(一) 2008-03-19 17:34 cppexplore
            @xushiwei
            麻煩做下修改再測試:
            void doAprPools1(LogT& log)
            {
            log.print("===== APR Pools =====\n");
            std::PerformanceCounter counter;
            for (int i = 0; i < N; ++i)
            {
            apr_pool_t* alloc;
            apr_pool_create(&alloc, m_pool);
            int* p = (int*)apr_palloc(alloc, sizeof(int));
            apr_pool_destroy(alloc);
            }
            counter.trace(log);
            }
            改成
            void doAprPools1(LogT& log)
            {
            int i;
            apr_pool_t* alloc;
            apr_pool_create(&alloc, m_pool);
            for (i = 0; i < N; ++i)
            {
            int* p = (int*)apr_palloc(alloc, sizeof(int));
            }
            apr_pool_destroy(alloc);

            apr_pool_t* alloc2;
            apr_pool_create(&alloc2, m_pool);
            log.print("===== APR Pools =====\n");
            std::PerformanceCounter counter;
            for (i = 0; i < N; ++i)
            {
            int* p = (int*)apr_palloc(alloc2, sizeof(int));
            }
            counter.trace(log);
            apr_pool_destroy(alloc2);
            }
            至于線程鎖的使用開銷,這里就先不考慮了。“apr_pool也是,顯式構(gòu)造allocator后不調(diào)用apr_allocator_mutex_set就是無鎖的實現(xiàn)。 ”  回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理(一) 2008-03-23 13:51 xushiwei
            to cppexplore: 請留意我的測試意圖。  回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理(一) 2008-03-24 12:28 cppexplore
            @xushiwei
            你的測試代碼對apr-pool不公平,首先(1)作為服務(wù)器,關(guān)心是長期運(yùn)行后的性能,而不是開始幾個請求的性能,一個服務(wù)器可能365天無間斷服務(wù),而只拿系統(tǒng)啟動2分鐘的性能來衡量1年的性能顯然不合適,而apr-pool開始申請內(nèi)存是直接new,釋放的時候才組織內(nèi)存池結(jié)構(gòu)。(2)對于集中處理的情況(類似你的測試代碼),內(nèi)存的申請是從同一個池中申請的,而不是申請一塊內(nèi)存,就必須先申請一個池。
            你的測試代碼,(1)是針對apr-pool性能最差的建池階段 (2)每申請一塊內(nèi)存,反復(fù)的從allocator創(chuàng)建銷毀內(nèi)存池,和實際的使用不相符
            而你的內(nèi)存池,則沒有建池階段,直接棧中建池,我認(rèn)為用上面寫過apr-pool測試代碼用來測試,才對apr-pool公平。

            其實我覺得對內(nèi)存池做這種性能對比沒意義,首先這是變長內(nèi)存池,不需要考慮釋放,性能對比也就只是測試申請階段的性能,而變長內(nèi)存池都是在已有大內(nèi)存上的指針滑動,都是常數(shù)步驟內(nèi)完成。因此和算法之間對比性能不同,完善的內(nèi)存池之間根本就沒有性能比較的必要。  回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理(一) 2008-03-24 15:40 xushiwei
            to cppexplore: 我的測試分了兩種情況,我想你關(guān)注的是測試2的對比數(shù)據(jù)。測試1在實際中并不常見,只是我要看的是allocator的伸縮性。至于內(nèi)存池的效率,我的觀念和你相反,既然它是基礎(chǔ)設(shè)施,那么它的性能調(diào)優(yōu)是非常關(guān)鍵的,比你去優(yōu)化任何其他東西都來得有效。而算法之間我比較關(guān)心復(fù)雜度,而不是非常關(guān)心性能調(diào)優(yōu)(微調(diào))。  回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理(一)[未登錄] 2008-03-25 09:04 cppexplore
            @xushiwei
            “它是基礎(chǔ)設(shè)施,那么它的性能調(diào)優(yōu)是非常關(guān)鍵的”,這句話我不反對,雖然我認(rèn)為對變長內(nèi)存池沒必要。不過你的測試代碼并沒有反映apr_pool的真實性能。  回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理(一) 2008-04-25 16:19 Simon
            不知道apr_pool使用在商業(yè)軟件中是否有版權(quán)問題?  回復(fù)  更多評論
              

            # re: 【原創(chuàng)】系統(tǒng)設(shè)計之 內(nèi)存管理(一) 2008-04-25 16:53 cppexplore
            它使用Apache License。允許免費(fèi)修改重發(fā)布,允許商業(yè)使用,允許不公布修改后的源代碼。  回復(fù)  更多評論
              

            # re: 【原創(chuàng)】技術(shù)系列之 內(nèi)存管理(一) 2008-10-23 13:23 cui
            apr_pool 不是預(yù)先申請大塊內(nèi)存嗎? 不然變長內(nèi)存池怎么實現(xiàn)?  回復(fù)  更多評論
              

            # re: 【原創(chuàng)】技術(shù)系列之 內(nèi)存管理(一) 2009-03-23 17:41 舵手
            內(nèi)存,內(nèi)存。。。  回復(fù)  更多評論
              


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


            国产激情久久久久影院老熟女免费| 大香伊人久久精品一区二区 | 欧美日韩精品久久久久| 精品久久久久久无码专区不卡| 久久久久国产精品人妻| 久久久www免费人成精品| 看全色黄大色大片免费久久久| 激情五月综合综合久久69| 国产精品成人99久久久久| 久久成人18免费网站| 久久久久人妻一区精品| 九九精品久久久久久噜噜| 无码国内精品久久综合88| 麻豆亚洲AV永久无码精品久久| 久久精品国产亚洲AV嫖农村妇女| av午夜福利一片免费看久久| 亚洲国产精品一区二区久久| 久久国产免费直播| 狠狠色丁香婷婷久久综合五月| 精品综合久久久久久98| 中文字幕久久波多野结衣av| 国产99久久精品一区二区| 久久久久亚洲AV成人网人人网站| 午夜精品久久久久久影视riav| 久久人人爽人人人人爽AV| 91视频国产91久久久| 久久久久亚洲爆乳少妇无| 色诱久久久久综合网ywww| 93精91精品国产综合久久香蕉| 久久国产AVJUST麻豆| 久久99精品综合国产首页| 亚洲国产精品一区二区三区久久 | 久久久久久精品久久久久| 国产69精品久久久久777| 欧美日韩精品久久久久| 东京热TOKYO综合久久精品 | 国产精品久久久久aaaa| 国产精品久久久久久久久久影院| 国产一级做a爰片久久毛片| 久久久噜噜噜久久中文字幕色伊伊| 久久99精品国产麻豆|