当mongodb在数据目录下创建新文件时,需要更多时间来创建:
第376行:1月15日星期四18:01:49.407 [FileAllocator]分配新数据文件> \ data \ db \ test.3,填充零... 第476行:1月15日星期四18:03:55.650 [FileAllocator]完成分配数据文件> \ data \ db \ test.3,大小:512MB,花费126.242秒
由于该节点在该节点无法与mongodb连接后给出以下错误。
{"错误":" {错误:'与[localhost:27017]的连接超时' }","等级":"错误","消息":"未捕获的异常:","时间戳& #34;:" 2015-01-15T20:45:03.702Z"}
我的理解是这个错误来自MongoMQ lib。我不知道如何处理它。任何人都可以帮助解决这个问题。
答案 0 :(得分:3)
Windows回答
此处可能适用的最明显的问题是,如果您使用的是Windows 7或Windows Server 2008.可以通过应用SERVER-8480来解决这些操作系统的问题(this hotfix)意味着MongoDB分配的数据文件必须用零填充。
与普通方法相比,这是一个漫长的过程。不幸的是,即使安装了修补程序,版本2.6和2.4 MongoDB也假设问题仍然存在于Windows 7或Server 2008上,无论如何都是零填充。版本2.8+通过专门检测修补程序并恢复为非零填充来解决问题。
为了让您了解其中的差异,以下是Windows 7上2.8.0-rc5(检测到修复程序)的示例日志行:
2015-01-22T16:56:51.749+0000 I STORAGE [FileAllocator] done allocating datafile E:\data\db\280\test.2, size: 2047MB, took 0.016 secs
这是来自同一台机器的示例日志行,使用版本2.6.5执行相同的分配:
2015-01-22T16:47:33.762+0000 [FileAllocator] done allocating datafile E:\data\db\265\test.2, size: 2047MB, took 112.071 secs
这是112.071秒而0.016秒。 Windows 8/2012或2.8+(一旦发布,当然安装了修补程序)似乎是分配给您带来问题的方法。
对于Windows上2.6.4之前的MongoDB版本,还有一些更常见的已知问题,最值得注意的是SERVER-13729和SERVER-13681,它们是用2.6.4解决的。
其余问题正在SERVER-12401中跟踪,并依赖于Microsoft的this hotfix来改进操作系统刷新内存映射文件。不幸的是,该修补程序仅适用于Windows 8和2012,但尚未针对Windows 7和2008提供。
因此,请确保您至少使用2.6.4+,如果可能的话,请使用Windows 8或2012.将远程存储上看到的任何性能与本地磁盘进行比较以确定这是否是一个影响因素也可能会有所帮助
Linux回答
(保存以防其他人在使用Linux时结束此处)
如果您使用支持的文件系统,这应该只需几毫秒。我怀疑你正在使用别的东西(也许是ext3
?),或者可能使用的是旧版本的Linux。
支持的文件系统使用fallocate()
来分配数据文件,这非常快。如果不支持,则必须通过填充零来分配文件,这将花费很长时间。
即使是这种情况,126秒零填充512MB文件也非常慢,这表明磁盘要么慢/坏,要么超额预订/饱和并且难以跟上。
如果你想评估MongoDB之外的分配,我已经编写了一个小的bash脚本到pre-allocate data files for MongoDB(用于测试目的),它使用前面提到的fallocate()
并以毫秒为单位完成多个千兆字节在我的测试系统上。