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

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

第一次添加效果很好，大约花费了 3 秒，这在我的测试机上还算不错；然而，未来添加同一文件需要更长的时间，长达 30 秒，最终 MongoDB 告诉我内存不足并崩溃了。

添加 10 个大小为 80Mb 的文件会导致在系统崩溃之前为我的数据库创建 8 个名为 dbaseName.0 到 dbaseName.7 的文件，它们的文件大小从文件 0 到 5 呈指数增长，从 16Mb 到 512Mb，然后文件 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)

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

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

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

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

因此，尽管看起来一个 80Mb 文件占用的空间比应有的多得多，但从某种意义上讲，这是有道理的。

这可以通过使用 --noprealloc 运行 mongod 来关闭，尽管建议仅在测试机器上这样做。

感谢您的回复！