Java 由于EC2实例上使用了所有内存，MongoDB性能缓慢

我们已经在EC2上创建了mongodb分片，每个服务器有3个m2 xlarg服务器，还有一个m2xlarge实例作为configdb和mongos

我们做了一项测试，插入了1.1亿个文档。每个文档大小为0.3KB。它提供了每秒55000次写入的理想结果

然而，我们观察到，一旦内存使用量接近15GB（实例的RAM量），Mongo的插入性能就会下降到每秒1000次插入，然后它会慢慢停止接受任何新的插入请求

假设缓存使用了所有的RAM，那么性能问题是可以理解的

不过，我们已经重新启动了所有服务器，在重新启动之后，我们仍然注意到mongo在前几百次插入之后的性能并不是很慢

有人能告诉我们这里有什么问题吗

---

我们假设当Mongo缓存大小接近实例的RAM限制时（因此使用所有RAM），性能将受到影响。然而，我们感到惊讶的是，一旦服务器重新启动并释放内存，性能就无法恢复。

根据我的经验，与其他解决方案相比，EC2 IO性能非常差。当所有东西都在RAM中时，MongoDB运行得非常快，但当集合（包括索引）不再适合RAM时，MongoDB依靠非常快的IO继续运行良好

我建议测量EC2实例的IO性能

如果还没有，可以通过将多个EBS卷分条到RAID配置中来显著改善EC2的IO。尽管如此，我预计与专用SAN相比，它的速度会很慢

---

如果您无法从EC2获得足够的IO，您的选择可能是使用更多实例将内容保留在RAM中，或者从EC2中移出。

您应该提供更多详细信息。在此期间，

mongostat

的输出是什么？还有

iostat-x2

。我在这里粘贴了统计信息：这很有趣。为什么你的碎片3有那么高的百分比？它是数据库的主分片吗？没有主服务器是分片1。AWS IO不仅速度慢，而且不可预测，因为它是与许多其他租户共享的资源。可能是到特定EC2实例的IO通道因其他客户的活动而饱和。感谢您的快速回复。鉴于我们目前的问题，我们只是在抛售目前在不久的将来不会被查询的文件。重新启动所有服务器后，它应该需要写入一个新文档，但仍然不需要新的写入请求。有什么问题吗？如果转储文档意味着发出MongoDB命令来删除文档，那么如果内存不足且IO速度非常慢，节点重新平衡和/或更新索引（以反映删除情况）实际上可能需要很长时间。谢谢eric。这里的转储意味着我们只插入文档。