[求助]求进程通信最有效率的方法选择

[addisjeams]

业务需要
一个32位x86的系统, win2003. 32g内存
分配20g给sql2005.
剩余12g空闲.

现在有一个程序, 本身数据量比较大, 计算量较低, 但大家知道的,"32位系统下单进程只有1.7g"

如果数据都从数据库获取, 那么延迟比内存缓存要慢得多.

实际上我测试了一下, 加载6w条数据,有400-500ms延迟.....这比进程内的操作慢多了.

单进程1.7g的限制很难突破, 所以我就想到的进程间通信.. 主进程负责逻辑, 另外多个进程负责加载数据(相当于缓存)

RPC太重量级了(简单用了一下,发现对现有的数据类修改太多), 于是我就自己实现tcp,序列化反序列化.(异步发送,环形缓存,多线程BeginSend)

我一个工作测试的电脑i5 3.5g 4核, 耗费100%才能达到16mb/s秒的处理量,我都绝望了.优化了一下才22mb每秒.
这完全无法接受....(仅仅只是传输文件,都不牵扯复杂的其他运算)

现在正在看管道, 内存映射和队列消息..

求做过相关应用的朋友,给点建议, 直接上哪个?

求指教

[fd34gs3yf]

32位系统不知最大支持4G内存吗？

[addisjeams]

引用 1 楼 war3tr 的回复:

32位系统不知最大支持4G内存吗？

引用 1 楼 war3tr 的回复:

32位系统不知最大支持4G内存吗？

你好win2003 32位支持32g内存 win2003 64位支持64g内存

[addisjeams]

引用 6 楼 sp1234 的回复:

“加载6w条数据”接下来干什么？

主进程A从DB加载6w数据,然后序列化,传递到进程B中,反序列化后放入内存里.当作缓存 进程A, 他只是一个逻辑处理, 他的业务流程,需要除了N个6w的数据.本身就需要用空间换取时间.差不多数秒内要遍历数据库中数据的50%(随着未来会降低比例,但总数据量会上升) 进程a就相当于一个类似于游戏逻辑处理器的东西 进程B以及更多的进程就相当于数据存放地. 进程a在规定的时间周期内,不断读取其他进程的数据, 然后计算, 然后更新. 嗯, 用游戏的机制形容, 还相当贴切. 就是数据量大了, 计算量本身一般

[addisjeams]

引用 3 楼 jy251 的回复:

大数据一般不会一次性读取吧，先不说数据库的压力，UI的压力也不小啊 既然你在看内存映射，看看能不能这样： 数据库用游标分段加载数据返回，大文件接收存储，这是一个单独线程。 另起一个线程，读取大文件数据并显示UI呢

你好, 数据本身不是各自独立的 主进程A在需要这些数据时, 很难预测会需要什么, 而且在一个周期循环内, 进程A必定需要所有这些数据的50%(就这样形容),很难做到需要什么数据再从DB加载什么数据(每次的延迟加起来就非常恐怖了) 另外 32位程序在64位系统,据说可以用2-4g(个人没有亲历过),但32位程序在32位系统,基本上就是1.7g,我就没看见过1.8g的.这方面网络上有资料,基本上内存只能有这么点

[addisjeams]

引用 7 楼 xuzuning 的回复:

数据库不是有内存表吗，为何不利用一下？

此功能是为了在 SQL Server 版本 6.5 中获得良好性能而提供的。DBCC PINTABLE 具有非常不利的副作用。其中包括可能损坏缓冲池。DBCC PINTABLE 不是必需的，并且已被删除以免产生其他问题。此命令的语法仍然有效，但不会影响服务器。 红色的文字表明，这个语句还是可以执行的，但是在sql server 2005及以后的版本，不起作用，执行了这个语句也不会有效果，也不会把这个表的数据锁定在内存中。 ---------------------------------------------------------------------------------------------- 部署的机器,恰好是2005,听说sql2012重新支持了.但2008r2对03的支持到头了

[jy251]

引用 9 楼 addisjeams 的回复:

你好, 数据本身不是各自独立的 主进程A在需要这些数据时, 很难预测会需要什么, 而且在一个周期循环内, 进程A必定需要所有这些数据的50%(就这样形容),很难做到需要什么数据再从DB加载什么数据(每次的延迟加起来就非常恐怖了) 另外 32位程序在64位系统,据说可以用2-4g(个人没有亲历过),但32位程序在32位系统,基本上就是1.7g,我就没看见过1.8g的.这方面网络上有资料,基本上内存只能有这么点

如果你是為了高速读取数据，那么放一个进程本身就无法支撑的数据量，设计本身上就有点问题啊。 你提到了数据池，那么可以尝试一下使用内存存储数据索引，文件存储实事实数据？把你关键的搜索要素放到索引中，真正的数据放到文件中？

[zhujinqiang]

6W条占了太多内存 那么一次只取6千行不？

[jy251]

大数据一般不会一次性读取吧，先不说数据库的压力，UI的压力也不小啊 既然你在看内存映射，看看能不能这样： 数据库用游标分段加载数据返回，大文件接收存储，这是一个单独线程。 另起一个线程，读取大文件数据并显示UI呢

[jy251]

另外，我记得以前看书的时候，好像提到单进程的使用内存空间是2-4G吧，具体不太记得了，但是这个1.7我是第一次听说

[正怒月神]

6W条数据并不是什么大数据。 你不是经常操作他，那么可以取出来放到缓存里。

[以专业开发人员为伍]

“加载6w条数据”接下来干什么？

[xuzuning]

数据库不是有内存表吗，为何不利用一下？

[addisjeams]

经过测试, 我最终的决定还是升级为64位系统....... ---------------------------------------------- 谢谢各位的参与 虽然考虑过,但最终没有用第三方的内存缓存方案

[吉普赛的歌]

不明白你要求这么高的东西， 居然还搞个 32 位…… 先改成 win2008+sqlserver2014 吧。 http://blog.csdn.net/yenange/article/details/50549937 或者 win2016 + sqlserver2016: http://blog.csdn.net/yenange/article/details/52980135

[以专业开发人员为伍]

即使是内存共享文件，你也需要自己编写文件数据块管理程序，分块管理数据的缓存。在 32 位系统上也不会有多大的空间（1G多），只有在 64 位系统上才能用到大内存。 而缓存其实只要缓存几十条记录就够了，并不是6万条记录。 并且缓存也不是以简单地对应多少条记录为标准的，而是以业务查询为标准的。例如 csdn 某个版块的首页列表，可以缓存起来。那么同一个帖子可能出现在首页列表缓存里，也同时出现在另外一种缓存里。并不是什么把几千万帖子给弄到内存里缓存。 你的缓存概念如果就是把数据库都搬到内存里（内存数据库），那么还是找一个独立的内存数据库（号称为缓存）系统吧。