我mongodb在实例（7GB RAM）上安装了（版本：2.0.8）EC2，数据大小仍然小于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.
这可能是什么原因？我应该怎么解决？任何帮助深表感谢...
@angela，@Asya，非常感谢您帮助我。
事实证明，延迟的主要原因是 mongodbGLOBAL 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）global lock在 mongodb 中都有一个。问题是，当一个不在内存中的条目发生更新时，mongo 必须先将数据加载到内存中，然后更新（在内存中），整个过程发生在global lock. 如果说整个事情需要 1 秒才能完成（0.75sec从磁盘加载数据并0.25sec在内存中更新），那么整个其余的更新调用都会等待（对于整个1 sec），并且这样的更新开始排队......你会注意到越来越多的应用程序服务器中的请求变慢。
它的解决方案（虽然听起来可能很傻）是query在制作update. 它的有效作用是将“加载数据到内存”（0.75 秒）部分移出，global lock这大大减少了您的lock percentage
2）全局锁的另一个主要原因是mongodb的数据flush到磁盘。基本上每 60 秒（或更少）mongodb（或操作系统）将数据写入磁盘，并global lock在此过程中保存 a。（这有点解释了随机慢查询）。在您的 MMS 统计信息中，请参阅图表background flush avg……如果它很高，则意味着您必须获得更快的磁盘。
在我们的案例中，我们迁移到一个新EBS optimized实例，EC2并将我们的配置IOPS从几乎减半100，服务器现在更加快乐。500background flush avg