MongoDB 随机慢查询 - EC2 IOPS答案

【问题标题】：MongoDB random slow queries - EC2 IOPSMongoDB 随机慢查询 - EC2 IOPS
【发布时间】：2013-03-04 23:28:01
【问题描述】：

我在EC2 实例（7GB RAM）上安装了mongodb（版本：2.0.8），但数据大小仍然小于1GB。我正在使用预配的100 IOPS 磁盘来提高磁盘性能。

问题是，我收到了一些随机的慢查询，如下所示，（来自 mongo 日志）

db.UserInfoShared 查询：{ _id: "999081873179" } ntoreturn:1 idhack:1 reslen:108 1919ms

几乎花了2 secs！

这只是对集合的_id 查找，其中大约有100,000 个条目，每个条目的大小都小于500 bytes。该实例仅运行 mongo，通常此类查找所需的时间少于 0.01 sec。

这可能是什么原因？我应该怎么解决？非常感谢任何帮助...

【问题讨论】：

您在同一个 mongod 进程上执行的其他操作是否会导致整体缓慢？如果可能的话，从您的日志文件中查看更多信息会很有帮助。此外，您应该尝试运行 Dex。 Dex 是一个开源工具，可以查看您的慢查询并推荐索引 (mongolab.org/#view=dex)。
另外，您应该在docs.mongodb.org/manual/administration/production-notes 上查看 MongoDB 的生产说明文档。例如，您应该使用 ext4 或 xfs 安装卷，并确保关闭 atime。
毫无疑问，此查询正在使用索引，因此 Dex 不太可能提供帮助。但是，关于您的 MongoDB 实例还在做什么的问题是相关的。例如，你写了很多东西吗？偶尔的慢查询可能与洗菜同时出现。通过 (a) 更多信息 (b) 在 MongoDB 用户 google 组上提问，您可能会得到更好的回应。
@angela，是的，它是 ext4，并且 atime 也被禁用。其实我遵循了一个非常详细的例子docs.mongodb.org/ecosystem/tutorial/…谢谢。
@AsyaKamsky，我确实每天都有一个 mongodump 运行......但延迟时间与它不一致。如何检查它是否发生磁盘刷新的原因？谢谢。

标签： mongodb amazon-ec2

【解决方案1】：

@angela、@Asya，非常感谢您帮助我。

事实证明，延迟的主要原因是 mongodb GLOBAL LOCK 本身。我们的锁定百分比平均为 5%，有时会达到 30-50% 的峰值，这会导致查询缓慢。

如果您遇到此问题，首先必须启用 mongodb MMS 服务 (mms.10gen.com)，这将使您深入了解数据库服务器中到底发生了什么。

在我们的案例中，LOCK PERCENTAGE 非常高，原因有很多。你要做的第一件事就是阅读关于并发的 mongodb 文档， http://docs.mongodb.org/manual/faq/concurrency/

锁的原因可以是应用层、mongodb或硬件。

1) 我们的应用程序做了很多 updates 并且每次更新（超过 100 ops/sec）在 mongodb 中都包含一个 global lock。问题是，当一个不在内存中的条目发生更新时，mongo 必须先将数据加载到内存中，然后更新（在内存中），整个过程发生在global lock 中。如果说整个事情需要 1 秒才能完成（0.75sec 从磁盘加载数据，0.25sec 在内存中更新），则整个其余的更新调用都将等待（对于整个 1 sec）并且此类更新开始排队……您会注意到应用服务器中的请求越来越慢。

解决方案（虽然听起来可能很傻）是在创建update 之前对相同的数据发送query。它的有效作用是将“加载数据到内存”（0.75 秒）部分移出global lock，这大大减少了您的lock percentage

2) 全局锁的另一个主要原因是mongodb的数据flush到磁盘。基本上每 60 秒（或更少）mongodb（或操作系统）将数据写入磁盘，并在此过程中保存 global lock。（这有点解释了随机慢查询）。在您的 MMS 统计信息中，请参阅 background flush avg 的图表...如果它很高，这意味着您必须获得更快的磁盘。

在我们的例子中，我们移动到EC2 中的一个新的EBS optimized 实例，并将我们配置的IOPS 从100 提升到500，这几乎将background flush avg 减半，服务器现在更快乐了.

【讨论】：