非映射虛擬記憶體和連接總數

我們有兩個 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。趨勢相當穩定，所以我不能說這裡有洩漏，但是記憶體去了哪裡？

任何的想法？

首先，讓我說，如果它相對穩定，您沒有記憶體洩漏，並且由於誤報的頻率，serverStatus() 中的註釋已在 2.2 中刪除。

非映射虛擬記憶體是 MongoDB 的內部資料結構和執行緒堆棧，本質上是任何不受磁碟文件支持的東西。正如您所提到的，這通常由每個連接 1MB 的連接堆棧驅動。在你的情況下，這聽起來應該在 1.1-1.2 GB 左右（除非你有一個連接峰值並且記憶體還沒有被回收）。

如果您正在執行大量的內聯映射/歸約、記憶體排序等，它們也可以提高非映射記憶體的使用率。如果您安裝MMS（免費），非映射記憶體是隨時間跟踪的統計數據之一，然後您可以輕鬆地將非映射統計數據的增加與數據庫上的活動相關聯。但是，如果您尚未執行它，則可能需要重新啟動該過程以再次從頭開始跟踪使用情況。

這種類型的使用分析通常比使用pmap（或類似的）來嘗試將記憶體綁定到程序中的特定部分更容易

最後，如果非映射使用失控，它有時可能是由libc malloc2.0 中的問題引起的——除其他原因外，這也是為什麼 2.2 版本附帶TCMalloc的原因。因此，如果沒有明顯原因，它仍然很高，2.2 可能值得一試。

引用自：https://serverfault.com/questions/426943