MongoDB GridFS 文件大小对于相对较小的文件来说很大

Question

我正在做一些测试，看看我们是否可以在 MongoDB 上使用 GridFS 来存储文件以供将来的应用程序使用；我正在使用 10gen 的 C# 驱动程序将一个 80Mb 的文件“上传”到数据库。

第一次添加很好，花了大约 3 秒，这在我的测试机器上还算不错；然而，以后添加同一个文件需要更长的时间，最多 30 秒，最终 MongoDB 告诉我它耗尽了内存并崩溃了。

添加 10 个大小为 80Mb 的文件会导致在系统崩溃之前为我的数据库创建 8 个文件，名为 dbaseName.0 到 dbaseName.7，它们的文件大小从 16Mb 呈指数增长到 512Mb，从文件 0 到 5，然后是文件 6 和7个都是512Mb。

这些文件不到 2Gb，显然第 10 次添加文件会使数据库超过 2Gb，这超出了我的 32 位测试版本的限制。

为什么存储 800Mb 的文件占用了 2Gb？是否有我遗漏的设置？

MongoDB 是否经常将整个 GridFS 保存在 RAM 中？如果是这样，磁盘的意义何在？如果我的生产服务器上只有 32Gb 的 RAM，我可以只在 GridFS 中存储 32Gb 吗？

我在我的 MongoGridFS 对象上使用了 EnsureIndexes 并且我检查了显示索引是为 GridFS 创建的数据库，所以 Mongo 不应该尝试将整个数据存储放入 RAM 中吗？

MongoDB 满足我们的所有需求，但我们需要它能够容纳大型文件集合；我是否遗漏了一些明显的东西？

堆栈跟踪:

Mon Oct 15 11:57:15 [conn15] insert busyNow.fs.chunks keyUpdates:0 locks(micros) w:112892 113ms
Mon Oct 15 11:57:15 [conn15] MapViewOfFileEx for /data/db/busyNow.7 failed with errno:8 Not enough storage is available to process this command. (file size is 536608768) in MemoryMappedFile::map

Mon Oct 15 11:57:15 [conn15]  busyNow.fs.chunks Fatal Assertion 16166
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\util\assert_util.cpp(124)                               mongo::fassertFailed+0x75
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\util\mmap_win.cpp(211)                                  mongo::MemoryMappedFile::map+0x4ce
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\mongommf.cpp(182)                                    mongo::MongoMMF::create+0xa3
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\pdfile.cpp(469)                                      mongo::MongoDataFile::open+0x141
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\database.cpp(280)                                    mongo::Database::getFile+0x34f
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\database.cpp(332)                                    mongo::Database::suitableFile+0x129
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\database.cpp(359)                                    mongo::Database::allocExtent+0x41
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\pdfile.cpp(1271)                                     mongo::outOfSpace+0x107
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\pdfile.cpp(1293)                                     mongo::allocateSpaceForANewRecord+0x5d
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\pdfile.cpp(1463)                                     mongo::DataFileMgr::insert+0x493
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\pdfile.cpp(1217)                                     mongo::DataFileMgr::insertWithObjMod+0x33
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\instance.cpp(761)                                    mongo::checkAndInsert+0x72
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\instance.cpp(821)                                    mongo::receivedInsert+0x4cd
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\instance.cpp(434)                                    mongo::assembleResponse+0x62a
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\db\db.cpp(192)                                          mongo::MyMessageHandler::process+0xe8
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\mongo\util\net\message_server_port.cpp(86)                    mongo::pms::threadRun+0x424
Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\third_party\boost\boost\thread\detail\thread.hpp(62)          boost::detail::thread_data<boost::_bi::bind_t<void,void (__cdecl*)(mongo::MessagingPort *),boost::_bi::list1<boost::_bi::value<mongo::MessagingPort *
> > > >::run+0x9Mon Oct 15 11:57:17 [conn15] mongod.exe  ...\src\third_party\boost\libs\thread\src\win32\thread.cpp(16707566)  boost::`anonymous namespace'::thread_start_function+0x47
Mon Oct 15 11:57:17 [conn15] mongod.exe  f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c(314)                _callthreadstartex+0x1b
Mon Oct 15 11:57:17 [conn15] mongod.exe  f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c(292)                _threadstartex+0x64
Mon Oct 15 11:57:17 [conn15]

***aborting after fassert() failure


Mon Oct 15 11:58:33 [initandlisten] connection accepted from 127.0.0.1:56308 #16 (3 connections now open)

Answer 1

好的；经过大量搜索后，似乎 MongoDB 在指数大小的文件中预先分配了最多 2Gb 的空间，之后每个文件将是 2G。

http://www.mongodb.org/display/DOCS/Excessive+Disk+Space

我的测试程序在后台文件(.0 - .7 等)中添加了 80Mb 文件，当数据 block 开始写入最后一个文件时，Mongo 预分配了另一个比上一个文件大得多的文件。

所以第一个 80Mb 文件填满了 16Mb 文件、32Mb 文件和 64Mb 背景文件，并且由于元数据占用了更多空间并且必须稍微占用 128Mb 文件，这会触发 mongo 预分配一个256Mb 文件总计 496Mb；随着更多文件的添加，更多文件被预分配，当我的测试机器上达到 2Gb 时，Mongo 无法访问该空间并崩溃。

因此，尽管看起来一个 80Mb 的文件占用的空间比它应该占用的空间多得多——但它以一种迂回的方式是有意义的。

这可以通过使用 --noprealloc 运行 mongod 来关闭，尽管这只推荐用于测试机器。

感谢您的回复!