我们的蒙古小学的non-mapped virtual memory统计一直是不变的，昨天之前我们从来没有想过这个。 昨天，一个devise不好的查询中发生的一系列意外的全面收集扫描导致了一个很大的放缓，其中mongod进程使用了100％的CPU，每个查询花了几十秒。
性能问题消失后，未映射的虚拟内存增加了一倍多，至今还没有下降。 它曾经保存在600MB左右; 现在大约是1.4GB 。 增长是立竿见影的，并且与经济放缓完全相关，从那以后它一点都没有改变。
连接的数量在整个过程中是完全不变的，所以我们可以肯定这不是。
什么可能导致这个？ 这是个问题吗？ 我们应该担心吗？
在EC2实例的Ubuntu 12.04 64位上运行。
由于虚拟内存是免费的，所以没有人会将其清理干净或将其用量降至最低。 只要居民区规模合理，我就不用担心了。
答案是取决于，但是这似乎不是一个问题，你不应该太担心，如果这是你所看到的唯一的行为。
MongoDB中的存储级别使用内存映射文件，因此所使用的虚拟内存总量可以是磁盘上所有数据库数据的大小。
系统中的驻留内存将代表MongoDB使用的实际工作集，并且根据您的使用/访问模式，它将随着时间的推移通常会随着主机上的总物理RAM而增长。 操作系统只会在看到需要的时候才分页输出这些数据，否则它将保持原样（对数据使用最近最less使用/ LRU和最less使用/ LFR方法）。 虚拟内存的使用量将随着这个增长而增长一点点，因为MongoDB在虚拟内存空间中维护着驻留内存的两个视图。
当MongoDB重新启动时，它将从头开始，并为您的工作数据集定义一个特定的时间框架，并定期，可预测的使用情况，您应该可以很好地表示您的工作集大小是以RAM的forms表示的。
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