执行大量写入时 MongoDB 光标超时答案

【问题标题】：MongoDB Cursor Timeouts while doing a lot of writes执行大量写入时 MongoDB 光标超时
【发布时间】：2011-05-09 18:28:39
【问题描述】：

我们有一个包含 2 个副本集的集群，每组有 3 个服务器。单个集合被分片。我们还有很多（8+）我们每天使用的集合。大部分数据都在分片集合中，其中包含近 1 亿条记录。

最近我们增加了获取 100 倍于我们之前获取的数据的要求，我们需要将其写入 mongodb。已设置一个守护程序来执行必要的写入操作，以使数据库保持最新状态。该脚本每秒执行超过 200 次写入，其中大部分写入所有单独的集合。

由于写入量如此之大，我们无法执行大量读取以用于分析目的。接收客户端和服务器端游标超时的组合（“未找到游标”）。

我们已尝试对读取执行限制/跳过方案，但问题仍然存在。由于我们需要大量写入和少量但大量读取，因此解决此问题的最佳行动方案是什么？

【问题讨论】：

标签： mongodb

【解决方案1】：

通常，在这种情况下，您希望开始查看导致时间的查询。然后你想看看硬件，看看有什么压力。

另外，日志中有什么异常吗？

基本上，我们需要确保您拥有： 1.正确搭建系统处理查询 2. 正确配置系统来处理数据量

【讨论】：

1.我们只使用 _id 字段查询我们的读取。 2. 我们的索引仅略大于内存大小，我们的 EC2 实例为 7.5 GB，每个 replSet 的索引为 9.5 GB。我们目前正在升级到 32 GB 主机。 3.我看不到任何瓶颈，只是问题正在完全读取数据。 4.我们通常在写入最多的集合上写锁定，否则我们很好。 5. 我们的处理器并没有真正承受太大压力。
iostat 和 mongostat 看起来如何？您是否在 EBS 驱动器上运行？突袭？他们的表现如何？
mongostat 显示锁定百分比浮动在 90% 左右，更新占据了图表的主导地位。我们目前在 master 上运行 ephemeral，在辅助节点上运行 EBS。 iostat 显示读取/秒为 622 和 365 写入/秒，读取可能很高，因为我们目前正在恢复 2 个 32GB 的服务器。
通常我会使用iostat -dxk 1。这有一个%util 列。如果该值很高，那么您正在对磁盘上的 IO 征税。
最大化 IO 的标准解决方案：RAID、更多 RAM 和分片。在进行分片之前，您需要从 RAID 和 RAM 开始。另外，请考虑使用slaveOkay 进行阅读。