動態(tài)共享內(nèi)存池設計

colin8080

在大型并發(fā)系統(tǒng)中進程之間通訊一般采用共享內(nèi)存，成千上萬不同大小的共享內(nèi)存隨時在創(chuàng)建，用完之后就立即釋放，如果采用單個共享內(nèi)存獨立創(chuàng)建和釋放，

多好的服務器也無法承載，唯有采用動態(tài)共享內(nèi)存池，一次申請創(chuàng)建一塊大的共享內(nèi)存區(qū)，并劃分成無數(shù)的小塊內(nèi)存，后續(xù)進程間通訊只需要memcpy賦值內(nèi)存塊，傳遞

內(nèi)存塊地址就ok。

1.首先在系統(tǒng)中開辟一塊大的共享內(nèi)存區(qū)10G，這塊有個疑問：共享內(nèi)存和服務器的物理內(nèi)存有沒有關系，最大共享內(nèi)存能不能超過物理內(nèi)存；

2.再次參考一般的二維哈希共享內(nèi)存設計，10G空間可以存儲最大數(shù)為100萬個元素(下面結(jié)構(gòu)體)，10級Hash，每次賦值根據(jù)nKey定位，釋放也可以根據(jù)nkey定位，

效率不用說，肯定很快。

struct KEY_INFO_T
{
    unsigned int nKey;
    unsigned int nLength;
    unsigned char* sValue[1024];//1K字節(jié)
};

但是上面的效率有個前提就是每次傳遞的數(shù)據(jù)不能超1k字節(jié)，如果將結(jié)構(gòu)體改為以下10K字節(jié)（應該足夠大），則可以存儲10萬個元素(下面結(jié)構(gòu)體)，10級Hash，

但是如果傳遞的消息只有1K的話，9K浪費了，比較可惜，如果服務器不能申請比較大的共享內(nèi)存區(qū)，浪費之后沒有空間就得等待，直接影響效率。

struct KEY_INFO_T
{
    unsigned int nKey;
    unsigned int nLength;
    unsigned char* sValue[1024*10];//10K字節(jié)

};

有沒有更好的動態(tài)共享內(nèi)存池設計方法，希望大家不吝賜教。

hanxin83

成千上萬不同大小的共享內(nèi)存隨時在創(chuàng)建，用完之后就立即釋放


誰見過這種模型?.....直接把作者拖出來打死---世界上不可能有比這種設計更垃圾的進程間通訊模型了.

所以一開始提出一個很高大上的問題, 結(jié)果問了一個弱弱的問題......
答題的心情都沒有---只想說一句:
懶得回答"要怎么做", 而是"要做什么"本來就是無意義的事情.

colin8080

回復 2# hanxin83


    這個需求是肯定會有的，我們系統(tǒng)有上百個進程，每個進程有3個隊列，每個隊列的的消息內(nèi)容部分用共享內(nèi)存存儲，便于進程間通信，

關鍵在于你怎么設計。

colin8080

鑒于申請?zhí)�大的共享�?nèi)存在映射時會影響到物理內(nèi)存，還得想辦法

將共享內(nèi)存空間壓縮，最初的設計方法浪費太多的內(nèi)存。

cokeboL

socket 收發(fā)包處理下，更優(yōu)勢的是能跨硬件

如果不是真有瓶頸，別提共享內(nèi)存有多快，木桶理論

irp

shared mem不管是page file backed or normal file backed, 要讀寫總是要耗RAM. 理論上reserve的地址空間可以大于RAM size, 假設你有4g RAM, 在64位os上mmap一個10g的文件應該不是問題。但是訪問過程會引起不斷的page fault, os會不斷地swap來滿足你的訪問請求。通過MAP_POPULATE 可以reserve一個很大的連續(xù)的地址范圍, 然后根據(jù)具體使用的尺寸分段提交。好處是提交的RAM是受workload大小影響的，workload小不會提交過多RAM，同時能保證虛擬地址是連續(xù)的。

heguangwu

回復 1# colin8080
照你這么說，申請多個不就得了，一個1K的池子，一個2K的池子，一個4K的池子，一個8K的池子，總之根據(jù)你的業(yè)務分配多種池子