做爲實時監控mongodb的利器,mongostat絕對是一把利刃,簡單好用,不過,要想仔細分析mongostat狀態,還少不了深入理解每個監控項的意義。html
# mongostat insert query update delete getmore command flushes mapped vsize res faults locked % idx miss % qr|qw ar|aw netIn netOut conn set repl time *79 87 *0 *0 0 13|0 0 354g 710g 10.2g 9 0 0 0|0 0|0 9k 666k 483 c56... SEC 15:07:17
下面分析每一項的含義:mongodb
inserts/s 每秒插入次數 query/s 每秒查詢次數 update/s 每秒更新次數
注:10條簡單的查詢可能比一條複雜的查詢速度還快, 因此數值的大小,意義並不大。但至少能夠知道,如今是否在處理查詢,是否在插入。若是是slave,數值前每每有一個*, 表明是replicate操做bash
getmore/s 查詢時遊標(cursor)的getmore操做 command/s 每秒的命令數,在主從系統中,會顯示兩個值 (例如:80|0),分別表明 本地|複製 命令的個數
注:一秒內執行的命令數好比批量插入,只認爲是一條命令意義不大。若是是slave,會顯示兩個值, local|replicated,經過這兩個數值的比較,或許能夠看出點問題。網絡
flushs/s 每秒執行fsync將數據寫入硬盤的次數。
注:通常都是0,或者1,經過計算兩個1之間的間隔時間,能夠大體瞭解多長時間flush一次。flush開銷是很大的,若是頻繁的flush,可能就要找找緣由了。app
mapped/s 全部的被mmap的數據量,單位是MB(這是 在mongostat 最後一次調用的總數據) vsize 虛擬內存使用量,單位MB (這是 在mongostat 最後一次調用的總數據) res 物理內存使用量,單位MB (這是 在mongostat 最後一次調用的總數據)
注:這個和你用top看到的同樣,mapped, vsize通常不會有大的變更, res會慢慢的上升,若是res常常忽然降低,去查查是否有別的程序狂吃內存。ide
faults/s 每秒訪問失敗數(只有Linux有),數據被交換出物理內存,放到swap。
注:不要超過100,不然就是機器內存過小,形成頻繁swap寫入。此時要升級內存或者擴展,大壓力下這個數值每每不爲0。若是常常不爲0,那就該加內存了。spa
推薦文章:http://huoding.com/2011/08/19/107線程
locked % 被鎖的時間百分比,儘可能控制在50%如下吧
注:MongoDB就一把讀寫鎖,這裏指的是寫鎖所住的時間百分比。這個數值過大(常常超過10%),那就是出情況了。htm
idx miss % 訪問加載 btree 節點時須要頁面故障的嘗試的索引百分比。
注:這是一個採樣值。若是過高的話就要考慮索引是否是少了,很是重要的參數, 正常狀況下,全部的查詢都應該經過索引,也就是idx miss爲0。若是這裏數值較大,是否是缺乏索引。blog
qr 客戶端等待從 MongoDB 實例讀取數據的隊列長度。 qw 客戶端等待向 MongoDB 實例寫入數據的隊列長度。 ar 執行讀取操做的活動客戶端的數目。 aw 執行寫入操做的活動客戶端的數目。
注:若是這兩個數值很大,那麼就是DB被堵住了,DB的處理速度不及請求速度。看看是否有開銷很大的慢查詢。若是查詢一切正常,確實是負載很大,就須要加機器了。
netIn The amount of network traffic, inbytes, received by the MongoDB instance. This includes traffic from mongostat itself. netOut The amount of network traffic, inbytes, sent by the MongoDB instance. This includes traffic from mongostat itself.
注:網絡帶寬壓力,通常MongoDB,網絡不會成爲瓶頸
conn 打開鏈接的總數。
注: MongoDB爲每個鏈接建立一個線程,線程的建立和釋放也是有開銷的。儘可能不要讓這個數值很大。
set 副本集的名稱。 repl 節點的複製狀態。
注:
M - master
SEC - secondary
REC - recovering
UNK - unknown
SLV - slave
time 時間戳
推薦文章;http://www.cnblogs.com/zhuque/archive/2013/03/29/2988577.html