performance - MongoDB 分片集群比独立节点慢 25

Question

我对这种情况感到困惑，并试图解决这个问题几天。我在三个 3 成员副本集(rs0、rs1 和 rs2)之上运行 3 个分片。到目前为止一切正常。数据分布在 3 个分片上，并在副本集中克隆。

但是:将数据导入其中一个副本集可以正常处理 40k 文档/秒，但启用分片会使整个过程减慢到仅 1.5k 文档/秒。

我已经通过不同的方法填充了数据:

• 在 mongo shell 中生成了一些随机数据(在我的 mongos 中运行)
• 通过 mongoimport 导入 JSON 数据
• 通过 mongorestore 从另一台服务器恢复 MongoDB 转储

所有这些都只产生 1.5k 文档/秒，这令人失望。 mongod 是每个 32GB 的物理 Xeon 盒子，3 个配置服务器是虚拟服务器(40 GB HDD，2 GB RAM，如果重要的话)，mongos 在我的应用服务器上运行。顺便说一句，1.5k inserts/s 的值不取决于分片键，专用分片键(单字段键和复合键)以及 _id 字段上的散列分片键的行为相同。

我尝试了很多，甚至两次重新安装了整个集群。问题是:这个设置的瓶颈是什么:

• 配置在虚拟服务器上运行的服务器？ -> 由于配置服务器的资源消耗低，应该不会有问题
• 蒙古人？ -> 在 HAproxy 后面的专用盒子上运行多个 Mongos 可能是一种替代方案，尚未测试过

Answer 1

让我们先算一下:您的文档有多大？请记住，根据您的写作问题，它们必须通过网络多次传输。

您可能会因为必须构建索引而遇到这种情况。

请试试这个:

1. 禁用 所有 索引除了 _id 的索引(无论如何，这是不可能的，iirc)
2. 加载您的数据
3. 重新启用索引。
4. 启用分片和平衡(如果尚未完成)

无论如何，这是将数据导入共享集群的建议方法，应该会大大加快导入速度。一些(小心!)摆弄 storage.syncPeriodSecs 和 storage.journal.commitIntervalMs 也可能有所帮助。

即使将数据存储在主分片上，也会发生延迟。根据索引的大小，它们可能会大大减慢批量操作。您可能还想查看 replication.secondaryIndexPrefetch 配置选项。

另一件事可能是您的 oplog 被填满的速度比复制发生的速度快。这里的问题:一旦它被创建，你就不能增加它的大小。我不确定在独立模式下删除和重新创建它是否安全，然后重新共享副本集，但我对此表示怀疑。所以安全的选择是让实例真正离开副本集，用更合适的 oplog 大小重新安装它，然后像第一次一样将实例添加到副本集中。如果您不关心数据，只需关闭副本集，调整配置文件中的 oplog 大小，删除数据目录并重新启动并重新初始化副本集。再次考虑您的问题，这听起来对我来说是最好的选择，因为 opllog 不涉及独立模式，iirc。

如果您仍然遇到同样的性能问题，我敢打赌是磁盘或网络 IO 的问题。

您有一个相当标准的设置，您的 mongos 实例运行在与您的 mongod 不同的机器上(无论是独立的还是副本集的主实例)。您可能需要检查几件事:

1. 名称解析延迟，用于从运行 mongos 实例的机器解析主分片和辅助分片的名称。我无法计算安装 nscd 提高各种操作性能的次数。
2. 从您的 mongos 实例到您的主分片的网络延迟。假设您的 AppServer 和集群之间有防火墙，您可能需要与相应的管理员交谈。
3. 如果您使用外部身份验证，请尝试衡量需要多长时间。
4. 使用某种隧道(例如 stunnel 或 SSL/TLS 等加密)时，请确保禁用名称解析。请记住，加密和解密可能需要相对较长的时间。
5. 测量 mongod 实例上的随机磁盘 IO