关于MongoDB在64位服务器上依然报 mmap failed with out of memory 错误的解决方法（附Mysql性能对比测试）

在32位平台，MongoDB和容易出现“mmap failed with out of memory”错误，因为在32位平台MongoDB不允许数据库文件（累计总和）超过2G，而64位平台没有这个限制。本想在新系统（64bit）中尝试采用MongoDB，但做一下MongoDB性能测试，结果却也报“mmap failed with out of memory”错误，好几天找不到答案，弄了个灰头土脸

今天终于找到了答案，原来是虚拟内存不足所致，这使我想起某年攒电脑，就是没声音，换驱动，换内存、换主板折腾了两天，最后才发现------------音箱电源没开！呵呵。google时发现很多同学也碰到类似问题，记录下来，希望有所帮助。

取消虚拟内存限制的方法：修改etc/profile文件，在文件最后加入一行

ulimit -v unlimited

保存，在命令行执行

# source /etc/profile

（重启linux也可以生效）


顺便记录测试结果：

# 硬件环境 ：suse11-64bit、xeon3.6*2、4G DDR333、scsi73G*2无raid 的老机器
# Client：java

1、连续“INSERT”3千万条简单数据（3个字段）：平均值大约在27700条/s；同时，插入第一个一百万和第九个一百万效率没有明显差异，数据文件体积大概在10G，比较大；

2、连续“INSERT”10万条标准数据（10个字段，含200字节文本字段）：平均值大约在19531条/s； 标准数据体积记录比大概为2.5G/百万（简单数据为：330M/百万）；

3、"SELECT"一万条数据（有索引）：46~58ms（个别的也达到180ms），一千条大概在6ms左右，非常稳定； CPU占用率也很低，2%左右；有一点需要说明的是，百万容量级别的数据库和千万容量级别的数据库在检索效率上几乎没有什么差异，我想，这是因为mongodb采用文件内存映射机制，不管多少数据，都是通过内存执行索引检索，所以数据库容量跟检索效率没有直接联系。

注意！在MongoDB中，没有索引的检索效率相当低下，所以在进行系统设计时，必须做好索引的规划，在这点上mongoDB和其他RDBMS其实是非常相似的。


# 对比Mysql 5.1的测试结果
# 采用InnoDB存储引擎
# Client：java+c3p0

1、连续“INSERT”1千万条标准数据（单条数据量和Mongodb测试中使用的等同）：平均值大约在3448条/s；同时，插入第一个一百万和第九个一百万效率没有明显差异，数据文件体积3.38G，标准数据体积记录比大概为346M/百万，对比Mongodb相当小了，仅仅相当其1/7；

2、"SELECT"一万条数据（有索引）：87~89ms（个别的也达到131ms，但极少），一千条大概在3~4ms左右； 百万容量级别的数据库和千万容量级别的数据库在检索效率上也没有什么差异。

3、“UPDATE”一万条数据（有索引）：120~123ms，一千条大概在12ms左右；

对比说明（仅针对千万级别数据库）：

I、插入效率Mongodb1.3是mysql5.1的 5.7 倍；

II、万条检索效率Mongodb1.3是mysql5.1的 2.35 倍；

II、千条检索效率mysql5.1是 Mongodb1.3 的 1.7 倍（这一回合Mysql获胜）；

III、Innodb的update单字段性能相当强悍，平均 83333条/秒（看来有时间我还得把Mongodb的update数据补上）

IV、在测试过程中我发现mysql的表现更为稳定，测试结果跳跃很小，在某次select循环中竟获得了完全一致的测试结果，一大串88ms，很惊艳。而相对的，Mongodb则产生了较大跳跃；

V、Mongodb在以5.7倍的插入效率完胜mysql的同时，它也损失了约7倍的空间利用率；

注意，你的测试结果很可能和我的有较大差异，原因是mysql不同参数配置对测试结果影响非常大，我记得曾看到网上某个相当全面的测试，结果Mongodb的插入效率竟然可以达到mysql的20倍之多，场景也是千万级别数据库。我怀疑他的mysql没有做优化，或者使用的是MyISAM引擎（MyISAM的插入效率和InnoDB能差一个数量级）。当然，也有可能人家善于做Mongodb优化，而这方面我是fish，呵呵

评论

16 楼 rosen 2010-06-20  

继续关注来Cassandra，尽管没说32位下2G的限制，但Memtable和SSTables结构，让我感到强行关机不丢数据是不可能的。

15 楼 rosen 2010-06-20  

为2G的限制和强行关机丢失数据而头痛，nosql，想说love不容易。

14 楼 bavnnsym 2010-05-17  

有没有办法解决在32位的平台下
不受数据库内容超2G限制

期待有人能给我正确的答案，
如果有，请详细解答

13 楼 wxmfly 2010-04-17  

很有参考价值，期待更深入的测试。

12 楼 com2con 2010-04-06  

最近在使用MongoDB进行开发，但关于MongoDB的资料太少了......

在MongoDB中可以使用嵌入型文档，如下：
userinfo{
username:keen,email:[e-mail],password:******,friends{
{friendID:1},
{friendID:2}
}
}

也可以把嵌入的文档独立出来，也就成了现在的关系型样式：
userinfo{username:keen,email:[e-mail],password:******}
friends{
{userID:3,friendID:1},
{userID:3,friendID:2}
}

这两种效率哪个更高？如果一个Collection嵌入的文档太多导致单个文档太大，超过MongoDB单个文档的限值，到时候能不能进行垂直分割？希望大家能够踊跃回答，谢谢。

11 楼 jamiesun 2010-03-16  

wtotal 写道

duka 写道

能否试试冷启电脑，数据是否有丢失？

这个问题怎么解决？

官方faq有这么一条：

Does an update fsync to disk immediately?

No, writes to disk are lazy. A write may hit disk a couple of seconds later. For example, if the database receives a thousand increments to an object within one second, it will only be flushed to disk once.

有人说在windows下强行关机导致本次开机以来数据全部丢失，这听起来有点夸张了。

不过内部具体的flush策略还需要深入了解下。

10 楼 jamiesun 2010-03-16  

http://www.cnblogs.com/JeffreyZhao/archive/2010/02/24/mongodb-tokyo-tyrant-benchmark-1-basic-cru-operations.html

这有一个测试其中有对update的测试。

mongodb通过主键更新记录性能超过了每秒5000次，对字段的修改是直接修改不用全部取出记录。可以说很NB了

9 楼 wtotal 2010-03-15  

duka 写道

能否试试冷启电脑，数据是否有丢失？

这个问题怎么解决？

8 楼 murainwood 2010-02-27  

duka 写道

能否试试冷启电脑，数据是否有丢失？

为这事儿头疼过....

7 楼 duka 2010-02-27  

能否试试冷启电脑，数据是否有丢失？

6 楼 yishh 2010-02-25  

想知道楼主的测试并发数是多少？

5 楼 chengj 2010-02-25  

mongodb的表名和字段名定义一定要简短，否则会占用大量的存储空间；mongodb加索引会对插入效率带来较大影响，不加会影响查询效率，这点要根据具体业务权衡。

4 楼 石中玉 2010-02-24  

我记得robbin(二楼的)写过一篇MongoDB的文章，很不错，大家有空去学习一下

3 楼 fengzl 2010-02-24  

最好来个对比

2 楼 smoke 2010-02-23  

一只在犹豫要不要采用mongodb

1 楼 robbin 2010-02-11  

很不错阿。就是插入的效率还是稍微有点低。