基于libev的Iserver进展之-多进程共享内存

基于libev，参考nginx的Iserver原型架构，已经完成了底层通讯部分，采用的是master-worker架构，主进程负责子进程的孵化和状态监控，由子进程进行select作业。

整个系统已经能跑起来了，暂未作性能测试。

现在遇到的问题是：由于采用多进程，未能处理好变量共享问题，导致系统log次序混乱。。。正在研究方案中：

1）共享内存互斥锁：性能代价太高

2）缓冲消息队列，由server统一经行处理，尚未知效果如何。。。

我们需要的内存管理技术，也许 slab 真是我们想参考的技术:http://www.cnblogs.com/inteliot/archive/2012/04/21/2461496.html

 

上午粗略地学习了一下nginx的内存管理和实现，本来想参考一下，移植过来的，感觉太庞大了，有点消化不了，所以比较靠谱的方案还是实现一个能满足需求的最小系统吧。

方案：共享内存+slab

看完下面这几篇文章，基本知道该怎么弄了，等待coding 以及测试结果吧：）

http://www.ibm.com/developerworks/cn/aix/library/au-spunix_sharedmemory/index.html?ca=drs- 

http://www.ibm.com/developerworks/cn/linux/l-ipc/part5/index1.html 

http://www.ibm.com/developerworks/cn/linux/l-ipc/part5/index2.html 

https://www.ibm.com/developerworks/cn/linux/l-linux-slab-allocator/#resources 

http://bbs.chinaunix.net/thread-2020986-1-1.html 

通过以上文章的学习，基本思路是这样的：

fork前将系统log文件映射到共享内存，同时创建信号量，然后由子进程写入log，信号量用来保证子进程写入的有效次序，

最后由master通过一定的机制和算法将共享内存syn进硬盘文件

测试代码出来了，效果很不错，不过运行时还有一些其他的小瑕疵，下图为写入log时的进程和记录索引：

 

之前出现的问题，是因为在mmap以后，对映射的对应文件进行了 文件操作（open）导致。这一点在上面的文章里面都强调了，一旦文件被映射成地址后，就不要用read write等文件操作方法操作了，否则就会出异常。

 

性能测试结果：

测试场景：

4核AMD处理器 2g内存  ab 也是在上面跑的。短连接，无业务逻辑

ab -n 100000 -c 10 http://192.168.1.200:9002/index.html

实际场景：

4核 8G内存 。长链接 

虽然没有挂业务，整体感觉性能还可以。

优化过程 

刚开始时，同样的命令，系统只能跑5-6K。经过分析，是log接口有问题。经过优化后轻松20K。

所以如果服务器性能有瓶颈，系统log是关键哈。

1）log分级

2）优化缓存，不要频繁操作磁盘文件

3）优化逻辑流程 

 

这章就到这里。等实际的场景完善后，会但独开篇详述的。