令我惊讶的是,我发现使用3.0版本与2.6.4相比,将相同文件导入相同的MongoDB(3.0)的速度要慢得多(> 20倍)。有人有同样的问题吗?以及如何解决?

详细信息如下:

  • 2.6.4可以为同一个json文件加载大约16,000行
    **-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版本不是很好的版本吗?

    最佳答案

    用20,000 numInsertionWorkers运行mongoimport过多。由于需要大量上下文切换以支持如此多的线程,因此应用程序的性能可能会下降。合适的工作人员数量将接近您在其上运行mongoimport的计算机上的内核数量。您可以通过测试找到合适的编号,从一个工作人员开始,监控性能,然后在每个后续测试中将编号翻倍[1,2,4,8,16,...]。您最终会发现一个性能不再提高的数字。届时您将超过正确数量的 worker 。

    在比较版本或流程之间的性能时,重要的是要确保测试运行之间的条件没有改变。如果服务器或网络在测试之间进行了更改,则很难在这两个过程之间进行有意义的比较。

    检查数据库本身是否处于相同状态。例如,如果您的导入工作负载是针对具有数据和预先存在的索引的数据库以及为空的数据库运行的,则性能会有所不同。

    检查文件系统和操作系统配置是否正确设置。我们的文档列出了您应设置以实现最佳性能的一组系统配置。 http://docs.mongodb.org/manual/administration/production-notes/

    检查运行mongoimport的服务器是否未饱和。寻找与mongoimport竞争的任何竞争进程,这些进程可能会消耗CPU,内存和网络带宽等资源。同样,检查运行mongod的服务器上是否存在竞争服务器资源的竞争进程。

    检查mongostat中排队的读取器和写入器的数量,mongostat中排队操作的数量少可以表明mongoimport进程是瓶颈。我怀疑mongoimport进程在数据库上游出现瓶颈。

    10-08 07:40