为什么 mongorestore 非常缓慢？答案

【问题标题】：Why is mongorestore painfully slow?为什么 mongorestore 非常缓慢？
【发布时间】：2013-08-14 13:09:43
【问题描述】：

我转储了一个只有 1 个集合和两个索引的数据库。该集合大约有 650 万份文件。当我试图恢复它时，令我惊讶的是，这个过程非常缓慢。 一些统计数据如下：

Wed Aug 14 12:34:08.346         Progress: 333818/1378309050 0%  (bytes)
Wed Aug 14 12:34:11.077         Progress: 1530246/1378309050    0%  (bytes)
Wed Aug 14 12:34:26.177         Progress: 2714544/1378309050    0%  (bytes)
Wed Aug 14 12:34:30.145         Progress: 3355627/1378309050    0%  (bytes)
Wed Aug 14 12:34:34.504         Progress: 3895668/1378309050    0%  (bytes)
Wed Aug 14 12:34:53.246         Progress: 4334159/1378309050    0%  (bytes)
Wed Aug 14 12:34:56.318         Progress: 4963878/1378309050    0%  (bytes)
Wed Aug 14 12:34:59.545         Progress: 5617794/1378309050    0%  (bytes)
Wed Aug 14 12:35:08.042         Progress: 6923804/1378309050    0%  (bytes)
Wed Aug 14 12:35:16.424         Progress: 7342576/1378309050    0%  (bytes)
Wed Aug 14 12:35:23.168         Progress: 7987560/1378309050    0%  (bytes)
Wed Aug 14 12:35:29.703         Progress: 9295140/1378309050    0%  (bytes)
Wed Aug 14 12:35:38.582         Progress: 9943758/1378309050    0%  (bytes)
Wed Aug 14 12:35:43.574         Progress: 11128693/1378309050   0%  (bytes)
Wed Aug 14 12:35:46.008         Progress: 11982044/1378309050   0%  (bytes)
Wed Aug 14 12:35:50.134         Progress: 12421241/1378309050   0%  (bytes)
Wed Aug 14 12:35:54.548         Progress: 13166696/1378309050   0%  (bytes)
Wed Aug 14 12:35:58.152         Progress: 13837935/1378309050   1%  (bytes)

从上面的数据可以推断，总转储（在 bson 中）大约是 1.3 Gigs。 mongorestore 需要 110 秒才能恢复 1%，即 13 MB。

如果有人对此有解释，请告诉我。我希望我无意中做错了什么，因为与本世纪的计算标准相比，这些数字太慢了。

编辑

我使用以下两个选项再次运行该命令，希望它们能加快进程：

--noobjcheck --noIndexRestore

但令我惊讶的是，这个过程现在变得更慢了！以下是一些统计数据。

Wed Aug 14 13:13:53.750     going into namespace [temp_raw_tweet_db.tweets]
Wed Aug 14 13:14:00.258         Progress: 871186/1378309050 0%  (bytes)
Wed Aug 14 13:14:04.424         Progress: 2070390/1378309050    0%  (bytes)
Wed Aug 14 13:14:07.482         Progress: 2921304/1378309050    0%  (bytes)
Wed Aug 14 13:14:11.895         Progress: 3647526/1378309050    0%  (bytes)
Wed Aug 14 13:14:57.028         Progress: 4984815/1378309050    0%  (bytes)
Wed Aug 14 13:15:01.015         Progress: 6202286/1378309050    0%  (bytes)
Wed Aug 14 13:15:05.051         Progress: 6797800/1378309050    0%  (bytes)
Wed Aug 14 13:15:08.402         Progress: 8133842/1378309050    0%  (bytes)
Wed Aug 14 13:15:12.712         Progress: 8872607/1378309050    0%  (bytes)
Wed Aug 14 13:15:15.259         Progress: 9964997/1378309050    0%  (bytes)
Wed Aug 14 13:15:19.266         Progress: 14684145/1378309050   1%  (bytes)
Wed Aug 14 13:15:22.364         Progress: 16154567/1378309050   1%  (bytes)
Wed Aug 14 13:15:29.627         Progress: 16754495/1378309050   1%  (bytes)
Wed Aug 14 13:15:35.225         Progress: 17726291/1378309050   1%  (bytes)
Wed Aug 14 13:15:39.447         Progress: 18333902/1378309050   1%  (bytes)
Wed Aug 14 13:15:43.717         Progress: 19055308/1378309050   1%  (bytes)
Wed Aug 14 13:15:46.481         Progress: 19305912/1378309050   1%  (bytes)
Wed Aug 14 13:15:49.902         Progress: 20038391/1378309050   1%  (bytes)
Wed Aug 14 13:15:53.868         Progress: 20389108/1378309050   1%  (bytes)
Wed Aug 14 13:15:58.578         Progress: 21127296/1378309050   1%  (bytes)
Wed Aug 14 13:16:03.706         Progress: 21837923/1378309050   1%  (bytes)
Wed Aug 14 13:16:56.512         Progress: 22092536/1378309050   1%  (bytes)
Wed Aug 14 13:16:59.035         Progress: 22583057/1378309050   1%  (bytes)
Wed Aug 14 13:17:02.313         Progress: 22817464/1378309050   1%  (bytes)
Wed Aug 14 13:17:05.044         Progress: 23178521/1378309050   1%  (bytes)
Wed Aug 14 13:17:26.023         Progress: 23434010/1378309050   1%  (bytes)
Wed Aug 14 13:17:39.161         Progress: 23670222/1378309050   1%  (bytes)
Wed Aug 14 13:17:42.846         Progress: 24049639/1378309050   1%  (bytes)
Wed Aug 14 13:17:59.125         Progress: 24284177/1378309050   1%  (bytes)
Wed Aug 14 13:18:02.722         Progress: 24515270/1378309050   1%  (bytes)
Wed Aug 14 13:18:06.827         Progress: 25018013/1378309050   1%  (bytes)
Wed Aug 14 13:18:09.234         Progress: 25253850/1378309050   1%  (bytes)
Wed Aug 14 13:18:14.282         Progress: 25617812/1378309050   1%  (bytes)
Wed Aug 14 13:18:46.296         Progress: 25983107/1378309050   1%  (bytes)
Wed Aug 14 13:18:51.303         Progress: 26604320/1378309050   1%  (bytes)
Wed Aug 14 13:18:55.500         Progress: 26971559/1378309050   1%  (bytes)
Wed Aug 14 13:19:00.656         Progress: 27444735/1378309050   1%  (bytes)
Wed Aug 14 13:19:04.100         Progress: 28064675/1378309050   2%  (bytes)

从 1% 到 2% 大约需要 4 分钟。这里肯定有严重的问题。

【问题讨论】：

有 13.78 亿条记录，但您声称它是 650 万条。您可以尝试 mongorestore 的 --dbpath 选项，但您必须为此停止 mongod。
列出的数字是字节数，不是记录数
从 mongodb v3.0 开始，您还可以使用 --numInsertionWorkersPerCollection - docs.mongodb.com/manual/reference/program/mongorestore/… 增加还原并发性
大型集合的导入似乎是一个相当缓慢的过程，尤其是在没有指定 --noIndexRestore 选项的情况下。我必须导入大约 7 GB 的存档和 gzip 压缩的数据库转储，其中一个集合中有大约 5400 万条记录。它似乎严重依赖机器资源。使用 8 个内核和 10 GB 内存比 2 和 4 得到更好的结果。更重要的是，使用索引恢复需要很长时间才能为该集合构建索引，而且似乎需要四个多小时。没有索引的恢复速度足够快，并且在一小时内建立了索引。
请问，您如何获得进度日志？

标签： mongodb ubuntu mongorestore

【解决方案1】：

这是一个非常老的帖子，但我最近遇到了类似的问题，可能是出于不同的原因，并且遇到了这个问题。

如果您碰巧在 AWS 上运行 mongo，请务必使用正确的实例和卷类型。

T 型实例具有 CPU 积分，在运行大型 mongorestore 进程时将用完。您的恢复将开始快速，然后缓慢爬行...它永远不会真正停止，但需要几天才能完成。

如果您尝试使用磁性 EBS 卷来节省一些钱，那也是个坏主意。 SC1 尤其错误，因为它在每秒操作数方面具有相似的信用... mongorestore 将消耗您所有的 IOPs 信用，无论您在几分钟内有多少，之后速度将降低到每秒 3 次操作并且恢复可能需要还有几周要完成。

我希望对某人有所帮助。

【讨论】：

【解决方案2】：

不幸的是，这些数字并不罕见。 mongorestore 在 3 亿个集合上需要几天时间。

你基本上有两个选择。

首先，只需进行长时间运行的还原并在一夜之间运行它：

nohup mongorestore [args] &

其次，复制数据库目录本身中的文件（默认为/data/db），而不是使用 mongodump/mongorestore。如果您可以关闭数据库一段时间，这是最好的。否则，您必须使用文件系统快照或类似的东西。查看更多官方 Mongo 简介：http://docs.mongodb.org/manual/core/backups/

【讨论】：

哦，是的，它很慢，非常慢
也许版本 4 在恢复过程方面更好，但恢复一个包含 4500 万条记录的集合只需要大约 15 分钟左右。主要技巧是不要立即构建索引，而是让它由自动化后台进程处理。注意！使用索引恢复非常慢，后台进程似乎要好得多。根据我的粗略计算，构建索引大约需要一个小时，而构建索引和恢复本身需要四个多小时。如果不是在后台构建，索引重建似乎会随着时间的推移而变慢。