我们有两个MongoDB数据节点（副本集） – 主要和次要。 我注意到non-mapped virtual memory相对较高，并且怀疑它们是否会影响我们的MongoDB性能（服务器通常每秒高达6-7K查询）。
在MMS中，有人指出：“对于非映射来说，使用大量内存的最常见情况是与数据库的连接非常多。
所以我们用db.serverStatus().mem来检查内存使用情况：
{ "bits" : 64, "resident" : 6846, "virtual" : 416797, "supported" : true, "mapped" : 205549, "mappedWithJournal" : 411098, "note" : "virtual minus mapped is large. could indicate a memory leak" }
注意：我们使用2.0.4，现在每个连接的默认堆栈大小应该是1MB。
目前的连接数是1.1K左右，但是未映射的虚拟内存（virtual-mappedWithJournal）大约是5699MB。 这个趋势是相当稳定的，所以我不能说这里有泄漏，但是记忆在哪里呢？
任何想法？
首先，让我说，如果它相对稳定，则不会有内存泄漏，并且serverStatus（）中的注释由于误报的频率而在2.2中被删除。
非映射的虚拟内存是MongoDB的内部数据结构和线程的堆栈，基本上没有任何磁盘上的文件支持。 如您所述，这通常由每个连接1MB的连接堆栈驱动。 在你的情况下，这听起来应该是在1.1-1.2 GB的标记（除非你有一个连接尖峰和内存还没有回收）。
如果你正在做大量的内联map / reduce，内存sorting等，他们也可以推动非映射内存的使用。 如果您安装MMS （免费），则非映射内存是随时间追踪的统计数据之一，您可以轻松地将非映射统计数据的增长与数据库上的活动相关联。 但是，如果您还没有运行它，则可能需要重新启动该过程以再次从头开始跟踪使用情况。
这种types的使用情况分析通常比使用pmap （或类似的）试图将内存绑定到进程内的特定片段更容易
最后，如果非映射的用法失控了，偶尔也可能由于2.0中的libc malloc问题引起 – 这也是为什么2.2版本随 TCMalloc 一起提供的原因 。 所以，如果没有一个明显的原因，这个值还是很高的，那么2.2值得一提。