共計 3013 個字符，預計需要花費 8 分鐘才能閱讀完成。
自動寫代碼機器人，免費開通
這篇文章將為大家詳細講解有關 Linux 中 MongoDB 是怎么使用內存的，丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。
Linux 如何管理內存
在 Linux 里 (別的系統也差不多)，內存有物理內存和虛擬內存之說，物理內存是什么自然無需解釋，虛擬內存實際是物理內存的抽象，多數情況下，出于方便性的考慮，程序訪問的都是虛擬內存地址，然后操作系統會把它翻譯成物理內存地址。
很多人會把虛擬內存和 Swap 混為一談，實際上 Swap 只是虛擬內存引申出的一種技術而已：操作系統一旦物理內存不足，為了騰出內存空間存放新內容，就會把當前物理內存中的內容放到交換分區里，稍后用到的時候再取回來，需要注意的是，Swap 的使用可能會帶來性能問題，偶爾為之無需緊張，糟糕的是物理內存和交換分區頻繁的發生數據交換，這被稱之為 Swap 顛簸，一旦發生這種情況，先要明確是什么原因造成的，如果是內存不足就好辦了，加內存就可以解決，不過有的時候即使內存充足也可能會出現這種問題，比如 MySQL 就有可能出現這樣的情況，解決方法是限制使用 Swap：
shell sysctl-wvm.swappiness=0
查看內存情況最常用的是 free 命令：
shell free-m
totalusedfreesharedbufferscached
Mem:32101293772723023925880
-/+buffers/cache:325828842
Swap:204702047新手看到 used 一欄數值偏大，free 一欄數值偏小，往往會認為內存要用光了。其實并非如此，之所以這樣是因為每當我們操作文件的時候，Linux 都會盡可能的把文件緩存到內存里，這樣下次訪問的時候，就可以直接從內存中取結果，所以 cached 一欄的數值非常的大，不過不用擔心，這部分內存是可回收的，操作系統會按照 LRU 算法淘汰冷數據。除了 cached，還有一個 buffers，它和 cached 類似，也是可回收的，不過它的側重點在于緩解不同設備的操作速度不一致造成的阻塞，這里就不多做解釋了。
知道了原理，我們就可以推算出系統可用的內存是 free+buffers+cached：
shell echo 2723+239+25880 |bc-l
28842
至于系統實際使用的內存是 used–buffers–cached：
shell echo 29377-239-25880 |bc-l
3258
除了 free 命令，還可以使用 sar 命令：
shell sar-r
kbmemfreekbmemused%memusedkbbufferskbcached
32243922964773290.1924611626070160
31163242975580090.5224599226157372
29595202991260491.0024555626316396
27922483007987691.5124568026485672
27182603015386491.7324568426563540
shell sar-W
pswpin/spswpout/s
0.000.00
0.000.00
0.000.00
0.000.00
0.000.00希望你沒有被 %memused 嚇到，如果不幸言中，請參考 free 命令的解釋。
Linux 中 MongoDB 是如何使用內存
目前，MongoDB 使用的是內存映射存儲引擎，它會把磁盤 IO 操作轉換成內存操作，如果是讀操作，內存中的數據起到緩存的作用，如果是寫操作，內存還可以把隨機的寫操作轉換成順序的寫操作，總之可以大幅度提升性能。MongoDB 并不干涉內存管理工作，而是把這些工作留給操作系統的虛擬緩存管理器去處理，這樣的好處是簡化了 MongoDB 的工作，但壞處是你沒有方法很方便的控制 MongoDB 占多大內存，事實上 MongoDB 會占用所有能用的內存，所以最好不要把別的服務和 MongoDB 放一起。
有時候，即便 MongoDB 使用的是 64 位操作系統，也可能會遭遇臭名昭著的 OOM 問題，出現這種情況，多半是因為限制了虛擬內存的大小所致，可以這樣查看當前值：
shell ulimit-a|grep virtual
多數操作系統缺省都是把它設置成 unlimited 的，如果你的操作系統不是，可以這樣修改：
shell ulimit-vunlimited
不過要注意的是，ulimit 的使用是有上下文的，最好放在 MongoDB 的啟動腳本里。
有時候，出于某些原因，你可能想釋放掉 MongoDB 占用的內存，不過前面說了，內存管理工作是由虛擬內存管理器控制的，所以通常你只能通過重啟服務來釋放內存，你一定不齒于這樣的方法，幸好可以使用 MongoDB 內置的 closeAllDatabases 命令達到目的：
mongo useadmin
mongo db.runCommand({closeAllDatabases:1})
另外，通過調整內核參數 drop_caches 也可以釋放緩存：
shell sysctl-wvm.drop_caches=1
平時可以通過 mongo 命令行來監控 MongoDB 的內存使用情況，如下所示：
mongo db.serverStatus().mem:
resident :22346,
virtual :1938524,
mapped :962283
}還可以通過 mongostat 命令來監控 MongoDB 的內存使用情況，如下所示：
shell mongostat
mappedvsizeresfaults
940g1893g21.9g0
940g1893g21.9g0
940g1893g21.9g0
940g1893g21.9g0
940g1893g21.9g0其中內存相關字段的含義是：
mapped：映射到內存的數據大小
visze：占用的虛擬內存大小
res：實際使用的內存大小
注：如果操作不能再內存中完成，結果 faults 列的數值不會是 0，視大小可能有性能問題。
在上面的結果中，vsize 是 mapped 的兩倍，而 mapped 等于數據文件的大小，所以說 vsize 是數據文件的兩倍，之所以會這樣，是因為本例中，MongoDB 開啟了 journal，需要在內存里多映射一次數據文件，如果關閉 journal，則 vsize 和 mapped 大致相當。
如果想驗證這一點，可以在開啟或關閉 journal 后，通過 pmap 命令來觀察文件映射情況：
shell pmap$(pidofmongod)
到底 MongoDB 配備多大內存合適? 寬泛點來說，多多益善，如果要確切點來說，這實際取決于你的數據及索引的大小，內存如果能夠裝下全部數據加索引是最佳情況，不過很多時候，數據都會比內存大，比如本文說涉及的 MongoDB 實例：
mongo db.stats()
dataSize :1004862191980,
indexSize :1335929664
}本例中索引只有 1G 多，內存完全能裝下，而數據文件則達到了 1T，估計很難找到這么大內存，此時保證內存能裝下熱數據即可，至于熱數據有多少，這就是個比例問題了，取決于具體的應用。如此一來內存大小就明確了：內存 索引 + 熱數據。
關于“Linux 中 MongoDB 是怎么使用內存的”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。
向 AI 問一下細節
