☰

非映射虚拟内存和连接总数

tag-icon • tag-icon mongodb nosql
非映射虚拟内存和连接总数

我们有两个 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）约为 5699 MB。趋势相当稳定，所以我不能说这里有泄漏，但内存去哪儿了？

任何想法？

答案1

首先，我要说的是，如果它相对稳定，则不会发生内存泄漏，并且由于误报频率较高，serverStatus() 中的注释已在 2.2 中删除。

非映射虚拟内存是 MongoDB 的内部数据结构和线程堆栈，本质上是任何不受磁盘文件支持的内容。正如您所提到的，这通常由连接堆栈驱动，每个连接 1MB。就您而言，这应该在 1.1-1.2 GB 左右（除非您遇到连接高峰并且内存尚未回收）。

如果你正在执行大量内联 map/reduce、内存排序等，它们也会增加非映射内存的使用。如果你安装彩信（免费），非映射内存是随时间跟踪的统计数据之一，然后您可以轻松地将非映射统计数据的增加与数据库上的活动关联起来。不过，如果您尚未运行它，则可能需要重新启动该过程以再次从头跟踪使用情况。

这种使用分析通常比使用地图（或类似方法）尝试将内存与进程内的特定部分关联起来

最后，如果非映射使用失控，有时可能是由libc malloc2.0 中的问题引起的 - 这就是为什么 2.2 版本已发货和TCMaloc 的因此，如果该值在没有明显原因的情况下仍然很高，那么 2.2 版可能值得一试。

相关内容