MongoDB 随机慢查询 - EC2 IOPS

Question

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

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

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

几乎 2 秒 !

这只是对一个集合的 _id 查找，该集合包含大约 100,000 个条目，每个条目的大小都小于 500 字节。该实例中仅运行了 mongo，通常此类查找不到 0.01 秒。

这可能是什么原因造成的？我应该如何解决它？非常感谢任何帮助...

Answer 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) 我们的应用程序进行了大量的更新并且每次更新(超过100 ops/sec)都持有一个全局锁 mongodb。问题是，当一个不在内存中的条目发生更新时，mongo 必须先将数据加载到内存中，然后再更新(在内存中)，整个过程发生在 global lock。如果说整个事情需要 1 秒才能完成(0.75sec 从磁盘加载数据，0.25sec 在内存中更新)，其余的更新调用等待(整个 1 秒)这样的更新开始排队……您会注意到您的应用服务器中的请求越来越慢。

它的解决方案(虽然听起来可能很愚蠢)是在进行更新 之前查询 相同的数据。它有效地做的是将“将数据加载到内存”(0.75 秒)部分从 global lock 中移出，这大大降低了您的 lock percentage

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

在我们的例子中，我们在 EC2 中迁移到一个新的 EBS 优化 实例，并将我们预置的 IOPS 从 100 到 500 这几乎将 background flush avg 减半，服务器现在更快乐了。