我们的 Mongo 主数据库的统计数据non-mapped virtual memory始终是恒定的，在昨天之前我们从未对此进行过多考虑。昨天，一个设计不良的查询意外地进行了一系列全集合扫描，导致速度大幅下降，该mongod进程占用了 100% 的 CPU，并且每个查询都要花费数十秒。
将有问题的查询卸载到我们的辅助服务器后，性能问题消失了，但非映射虚拟内存增加了一倍多，此后一直没有下降。它过去保持在约600MB；现在约为1.4GB。增长是立竿见影的，与速度下降完全相关，此后一直没有改变。
连接的数量始终保持完全恒定，因此我们可以肯定事实并非如此。
这可能是什么原因造成的？这是一个问题吗？我们应该担心吗？
在 EC2 实例上 64 位 Ubuntu 12.04 上运行。
答案1
因为虚拟内存实际上是空闲的，所以没人会费心清理它或尽量减少它的使用。只要常驻内存集大小合理，我就不会担心这个问题。
答案2
答案是这取决于但这似乎不是一个问题，如果这是您所看到的唯一行为，那么您不应该太担心。
MongoDB 中的存储级别使用内存映射文件，因此使用的总虚拟内存可以是磁盘上所有 DB 数据的大小。
系统上的常驻内存将代表 MongoDB 使用的实际工作集，并且根据您的使用/访问模式，它通常会随着时间的推移增长到主机上的总物理 RAM。操作系统只有在需要时才会将这些数据分页，否则它将保持原样（它对数据使用最近最少使用/LRU 和最不频繁使用/LFR 方法）。虚拟内存使用量将与此同步增长，速度略高于常驻使用量的两倍，因为 MongoDB 在虚拟内存空间中维护了两种常驻内存视图。
当 MongoDB 重新启动时，它会从头开始，并为您的工作数据集提供一个特定的时间范围，并定期、可预测地使用，您应该可以很好地了解您的工作集在 RAM 方面的大小。
MongoDB 的文档包含一些有助于描述其如何使用内存的进一步信息： http://docs.mongodb.org/manual/faq/storage/#faq-storage-memory-mapped-files
MongoDB 存储层的更深层技术视图如下： http://www.mongodb.com/presentations/understanding-mongodb-storage-performance-and-data-safety