令我惊讶的是,我发现使用3.0版本与2.6.4将同一文件导入同一个MongoDB(3.0)要慢得多(> 20倍)。有没有人有同样的问题?以及如何解决它?
以下是详细信息:
2.6.4为同一个json文件加载大约16K行
**-logbash-3.2$ mongoimport --host mcp-mongo-dev-1201.sea2.rhapsody.com:27017 --db media
--collection media --upsert --upsertFields _id --type json --file /data/xxx.json
connected to: mcp-mongo-dev-1201.sea2.rhapsody.com:27017
2015-10-08T15:24:02.007-0700 Progress: 8860712/5024041951 0%
2015-10-08T15:24:02.007-0700 54900 18300/second
2015-10-08T15:24:05.004-0700 Progress: 15590853/5024041951 0%
2015-10-08T15:24:05.004-0700 96900 16150/second**
这是3.0运行:
-logbash-3.2$ mongoimport30 --version
mongoimport version: 3.0.6
git version: 7588eb887549bd5d2fc7bbc08f7c62d4b29b9d75
-logbash-3.2$ mongoimport30 --host mcp-mongo-dev-1201.sea2.rhapsody.com:27017 --db media
--collection media --upsertFields _id --type json --file /data/mediaingestor2.json --numInsertionWorkers 20000 -v
2015-10-08T15:53:04.393-0700 using upsert fields: [_id]
2015-10-08T15:53:04.393-0700 filesize: 5024041951 bytes
2015-10-08T15:53:04.393-0700 using fields:
2015-10-08T15:53:04.396-0700 connected to: mcp-mongo-dev-1201.sea2.rhapsody.com:27017
2015-10-08T15:53:04.396-0700 ns: media.media
2015-10-08T15:53:04.396-0700 connected to node type: replset
2015-10-08T15:53:04.397-0700 using write concern: w='majority', j=false, fsync=false, wtimeout=0
2015-10-08T15:53:04.397-0700 using write concern: w='majority', j=false, fsync=false, wtimeout=0
2015-10-08T15:53:07.393-0700 [........................] media.media 1.5 MB/4.7 GB (0.0%)
2015-10-08T15:53:10.393-0700 [........................] media.media 1.5 MB/4.7 GB (0.0%)
2015-10-08T15:53:13.393-0700 [........................] media.media 1.5 MB/4.7 GB (0.0%)
2015-10-08T15:53:16.393-0700 [........................] media.media 1.5 MB/4.7 GB (0.0%)
2015-10-08T15:53:19.393-0700 [........................] media.media 1.5 MB/4.7 GB (0.0%)
在MongoDB方面,我使用mongostat
来查看更新的数量大约为400,这比上面的2.6.4版本的16K小得多。请注意,我也试过--numInsertionWorkers 20000
,它应该让它更快,但它似乎与不使用此选项相同。也许我使用的git版本不是很好的?
答案 0 :(得分:1)
使用20,000 numInsertionWorkers运行mongoimport是过分的。由于支持这么多线程的大量上下文切换,应用程序可能会失去性能。正确数量的工作人员将更接近您正在运行mongoimport的计算机上的核心数量。您可以通过测试找到正确的数字,从单个工作人员开始,监控性能,然后在每个连续测试中加倍数[1,2,4,8,16,...]。您最终会找到一个性能不再提高的数字。那时你将超过正确数量的工人。
在比较版本或流程之间的性能时,确保测试运行之间的条件无法改变非常重要。如果服务器或网络从测试变为测试,则很难在两个进程之间进行有意义的比较。
检查数据库本身是否处于相同状态。例如,如果针对具有数据和预先存在的索引以及数据库为空的数据库运行导入工作负载,则会出现性能差异。
检查文件系统和操作系统配置是否设置正确。我们的文档列出了您应设置的一组系统配置,以获得最佳性能。 http://docs.mongodb.org/manual/administration/production-notes/
检查运行mongoimport的服务器是否未饱和。在与mongoimport的竞争中寻找可能消耗诸如CPU,内存和网络带宽等资源的任何竞争过程。同样,检查运行mongod的服务器,以查找争用服务器资源的竞争进程。
检查mongostat中排队的读取器和写入器的数量,mongostat中的少量排队操作可以指示mongoimport进程是瓶颈。我怀疑mongoimport进程是数据库上游的瓶颈。