mongodb的記憶體總結

純手打，隻是總結了通過多種方式檢視mongodb的記憶體使用情況，并沒能提出有效的減少mongodb的記憶體的方法。

都說mongodb吃記憶體比較厲害，确實很厲害，我的資料級别到達了 4千萬，資料量大概是140G，幾天下來的話，130G的記憶體盤，到了60%，沒有找到很好的辦法前，每次都是重新開機mongodb，新手，我也不太清楚這個資料量是處于一個怎樣的位置，有怎樣的優良的解決辦法，知道的麻煩告知一下，跪謝。

為啥這麼吃記憶體呢，mongodb使用的是記憶體映射存儲引擎，即Memory Mapped Storage Engine，簡稱MMAP，MMAP可以把磁盤檔案的一部分或全部内容直接映射到記憶體，這樣檔案中的資訊位置就會在記憶體中有對應的位址空間，把磁盤IO操作轉換成記憶體操作，

但壞處是你沒有方法很友善的控制MongoDB占多大記憶體，事實上MongoDB會占用所有能用的記憶體，是以最好不要把别的服務和MongoDB放一起。之是以會有這個總結，就是因為曾經将web服務與mongodb放在一起，導緻負載間歇性的劇增，web服務直接被伺服器自動重新開機了，當然這是後話。

如果想知道mongodb的記憶體使用情況，可以有一些幾個操作：

top

<a href="http://s3.51cto.com/wyfs02/M01/7B/59/wKiom1bMIF6ibvzZAAA12zDMeao710.png" target="_blank"></a>

shift+m，如果不出意外的話，mongodb應該居于首位了，

VIRT:虛拟記憶體

RES:實際使用記憶體

%MEM:記憶體使用比

剛重新開機過，記憶體占用還不算多

2.mongostat

<a href="http://s5.51cto.com/wyfs02/M02/7B/59/wKioL1bMIyuzQCyFAABI-UKDuKs771.png" target="_blank"></a>

mapped：映射到記憶體的資料大小，

vsize：虛拟記憶體，是mapped的2倍

res: 實際使用的記憶體，如果res經常突然下降，去查查是否有别的程式狂吃記憶體

conn：目前的連接配接數

這裡的vsize,res與top的一緻，conn如果一直都很高的話，也是有問題的，lockedb如果很高的話（經常超過），說明有問題很大了，曾經因為很多python腳本規定時間跑不完，導緻連接配接一個接着一個，最終lockdb到了50% 

3.db.stats()

<a href="http://s1.51cto.com/wyfs02/M01/7B/5A/wKioL1bMKNWhWlp4AAAiC6o21ms338.png" target="_blank"></a>

db:目前資料庫

collections：目前資料多少張表

objects：目前資料庫所有表多少條資料

dataSize：所有資料的總大小

storageSize：所有資料占的磁盤大小

indexes：索引數

indexSize：索引大小

fileSize：預配置設定給資料庫的檔案大小

其實這個并不能說顯示記憶體的什麼情況，隻能說能顯示整個資料庫的一個狀态status

4.db.serverStatus()

<a href="http://s1.51cto.com/wyfs02/M00/7B/5B/wKioL1bMK1KTkGGqAABEE5vuWf8819.png" target="_blank"></a>

這個指令在單獨的個别db中，并不能顯示出任何結果，需要在admin 這個db中才有效，測試可以看到很多資訊顯示，如connections，current為目前的連接配接，available為可用的連接配接

我們常用的話，不會顯示這麼多的資訊，一般需要什麼就顯示什麼。如記憶體使用情況

5.db.serverStatus().mem

<a href="http://s1.51cto.com/wyfs02/M00/7B/5C/wKioL1bMLIeSuykvAAAPMe1ELvc677.png" target="_blank"></a>

virtual:虛拟記憶體的大小

mapped：映射到記憶體的資料大小

這裡虛拟記憶體是mapped的兩倍，是因為我們開啟了Journal日志，需要在記憶體中多映射一次，大概就是它的兩倍了。如果關閉Journal日志，虛拟記憶體大小将和mapped大小相當

我常用的大概就是top和mongostat，每次看到記憶體比較大的時候，采用的辦法就是重新開機服務，但是這并不能解決問題，隻是暫緩問題，有解決辦法的麻煩告知一聲，跪謝。

      本文轉自布拉君君 51CTO部落格，原文連結http://blog.51cto.com/5148737/1744408：，如需轉載請自行聯系原作者