动态共享内存池设计

colin8080

在大型并发系统中进程之间通讯一般采用共享内存，成千上万不同大小的共享内存随时在创建，用完之后就立即释放，如果采用单个共享内存独立创建和释放，

多好的服务器也无法承载，唯有采用动态共享内存池，一次申请创建一块大的共享内存区，并划分成无数的小块内存，后续进程间通讯只需要memcpy赋值内存块，传递

内存块地址就ok。

1.首先在系统中开辟一块大的共享内存区10G，这块有个疑问：共享内存和服务器的物理内存有没有关系，最大共享内存能不能超过物理内存；

2.再次参考一般的二维哈希共享内存设计，10G空间可以存储最大数为100万个元素(下面结构体)，10级Hash，每次赋值根据nKey定位，释放也可以根据nkey定位，

效率不用说，肯定很快。

struct KEY_INFO_T
{
    unsigned int nKey;
    unsigned int nLength;
    unsigned char* sValue[1024];//1K字节
};

但是上面的效率有个前提就是每次传递的数据不能超1k字节，如果将结构体改为以下10K字节（应该足够大），则可以存储10万个元素(下面结构体)，10级Hash，

但是如果传递的消息只有1K的话，9K浪费了，比较可惜，如果服务器不能申请比较大的共享内存区，浪费之后没有空间就得等待，直接影响效率。

struct KEY_INFO_T
{
    unsigned int nKey;
    unsigned int nLength;
    unsigned char* sValue[1024*10];//10K字节

};

有没有更好的动态共享内存池设计方法，希望大家不吝赐教。

hanxin83

成千上万不同大小的共享内存随时在创建，用完之后就立即释放


谁见过这种模型?.....直接把作者拖出来打死---世界上不可能有比这种设计更垃圾的进程间通讯模型了.

所以一开始提出一个很高大上的问题, 结果问了一个弱弱的问题......
答题的心情都没有---只想说一句:
懒得回答"要怎么做", 而是"要做什么"本来就是无意义的事情.

colin8080

回复 2# hanxin83


    这个需求是肯定会有的，我们系统有上百个进程，每个进程有3个队列，每个队列的的消息内容部分用共享内存存储，便于进程间通信，

关键在于你怎么设计。

colin8080

鉴于申请太大的共享内存在映射时会影响到物理内存，还得想办法

将共享内存空间压缩，最初的设计方法浪费太多的内存。

cokeboL

socket 收发包处理下，更优势的是能跨硬件

如果不是真有瓶颈，别提共享内存有多快，木桶理论

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一个很大的连续的地址范围, 然后根据具体使用的尺寸分段提交。好处是提交的RAM是受workload大小影响的，workload小不会提交过多RAM，同时能保证虚拟地址是连续的。

heguangwu

回复 1# colin8080
照你这么说，申请多个不就得了，一个1K的池子，一个2K的池子，一个4K的池子，一个8K的池子，总之根据你的业务分配多种池子