你的MongoDB是否健康?
mongodb
mongostat是mongdb自帶的狀態檢測工具,在命令行下使用。它會間隔固定時間獲取mongodb的當前運行狀態,並輸出。若是你發現數據庫忽然變慢或者有其餘問題的話,你第一手的操做就考慮採用mongostat來查看mongo的狀態。數據庫
它的輸出有如下幾列:服務器
inserts/s 每秒插入次數網絡
query/s 每秒查詢次數併發
update/s 每秒更新次數app
delete/s 每秒刪除次數ide
getmore/s 每秒執行getmore次數高併發
command/s 每秒的命令數,比以上插入、查找、更新、刪除的綜合還多,還統計了別的命令工具
flushs/s 每秒執行fsync將數據寫入硬盤的次數。性能
mapped/s 全部的被mmap的數據量,單位是MB,
vsize 虛擬內存使用量,單位MB
res 物理內存使用量,單位MB
faults/s 每秒訪問失敗數(只有Linux有),數據被交換出物理內存,放到swap。不要超過100,不然就是機器內存過小,形成頻繁swap寫入。此時要升級內存或者擴展
locked % 被鎖的時間百分比,儘可能控制在50%如下吧
idx miss % 索引不命中所佔百分比。若是過高的話就要考慮索引是否是少了
q t|r|w 當Mongodb接收到太多的命令而數據庫被鎖住沒法執行完成,它會將命令加入隊列。這一欄顯示了總共、讀、寫3個隊列的長度,都爲0的話表示mongo毫無壓力。高併發時,通常隊列值會升高。
conn 當前鏈接數
time 時間戳
profiler能夠監控具體某個數據庫查詢慢的以及不慢。
Profiler默認是關閉的,你能夠選擇所有開啓,或者有慢查詢的時候開啓。
> use test switched to db test > db.setProfilingLevel(2); {"was" : 0 , "slowms" : 100, "ok" : 1} // "was" is the old setting > db.getProfilingLevel()
查看Profile日誌
> db.system.profile.find().sort({$natural:-1}) {"ts" : "Thu Jan 29 2009 15:19:32 GMT-0500 (EST)" , "info" : "query test.$cmd ntoreturn:1 reslen:66 nscanned:0 query: { profile: 2 } nreturned:1 bytes:50" , "millis" : 0} ...
3個字段的意義
ts:時間戳
info:具體的操做
millis:操做所花時間,毫秒
很少說,此處有官方文檔。注意,形成滿查詢多是索引的問題,也多是數據不在內存形成所以磁盤讀入形成。
Mongodb自帶了Web控制檯,默認和數據服務一同開啓。他的端口在Mongodb數據庫服務器端口的基礎上加1000,若是是默認的Mongodb數據服務端口(Which is 27017),則相應的Web端口爲28017
這個頁面能夠看到
當前Mongodb的全部鏈接
各個數據庫和Collection的訪問統計,包括:Reads, Writes, Queries, GetMores ,Inserts, Updates, Removes
寫鎖的狀態
以及日誌文件的最後幾百行(CentOS+10gen yum 安裝的mongodb默認的日誌文件位於/var/log/mongo/mongod.log)
Sniffer,中文能夠翻譯爲嗅探器,是一種基於被動偵聽原理的網絡分析方式。使用這種技術方式,能夠監視網絡的狀態、數據流動狀況以及網絡上傳輸的信息。
Mongodb提供了一個sniffer工具:mongosniff,這個工具能夠從底層監控有哪些命令傳送給了Mongodb,祥見官網: http://docs.mongodb.org/manual/reference/program/mongosniff/
mongotop提供了一個方法,用來跟蹤一個MongoDB的實例,查看哪些大量的時間花費在讀取和寫入數據
獲取當前數據庫的信息,好比Obj總數、數據庫總大小、平均Obj大小等
> use test switched to db test > db.stats() { "collections" : 9, "objects" : 4278845, "avgObjSize" : 224.56603031892953, "dataSize" : 960883236, "storageSize" : 1195438080, "numExtents" : 59, "indexes" : 13, "indexSize" : 801931264, "fileSize" : 6373244928, "ok" : 1 }
獲取服務器的狀態
{ "version" : "1.6.5", "uptime" : 7208469, "uptimeEstimate" : 7138829, "localTime" : "Wed Oct 26 2011 22:23:07 GMT+0800 (CST)", "globalLock" : { "totalTime" : 7208469556704, "lockTime" : 4959693717, "ratio" : 0.000688036992871448, "currentQueue" : { "total" : 0, "readers" : 0, "writers" : 0 } }, "mem" : { "bits" : 64, "resident" : 3131, "virtual" : 6172, "supported" : true, "mapped" : 4927 }, "connections" : { "current" : 402, "available" : 2599 }, "extra_info" : { "note" : "fields vary by platform", "heap_usage_bytes" : 832531920, "page_faults" : 8757 }, "indexCounters" : { "btree" : { "accesses" : 2821726, "hits" : 2821725, "misses" : 1, "resets" : 0, "missRatio" : 3.543930204420982e-7 } }, "backgroundFlushing" : { "flushes" : 120133, "total_ms" : 73235923, "average_ms" : 609.6236920746173, "last_ms" : 1332, "last_finished" : "Wed Oct 26 2011 22:22:23 GMT+0800 (CST)" }, "cursors" : { "totalOpen" : 0, "clientCursors_size" : 0, "timedOut" : 238392 }, "repl" : { "ismaster" : true }, "opcounters" : { "insert" : 269351, "query" : 19331151, "update" : 14199331, "delete" : 1, "getmore" : 145575, "command" : 55982302 }, "asserts" : { "regular" : 0, "warning" : 0, "msg" : 0, "user" : 27, "rollovers" : 0 }, "ok" : 1 }
須要關心的地方:
connections 當前鏈接和可用鏈接數,聽過一個同行介紹過,mongodb最大處理到2000個鏈接就不行了(要根據你的機器性能和業務來設定),因此設大了沒意義。設個合理值的話,到達這個值mongodb就拒絕新的鏈接請求,避免被太多的鏈接拖垮。
indexCounters:btree:misses 索引的不命中數,和hits的比例高就要考慮索引是否正確創建。你看個人」missRatio」 : 3.543930204420982e-7,很健康吧。因此miss率在mongostat裏面也能夠看
其餘的都能自解釋,也不是查看mongo健康情況的關鍵,就不說明了。
Mongodb 的命令通常很快就完成,可是在一臺繁忙的機器或者有比較慢的命令時,你能夠經過db.currentOp()獲取當前正在執行的操做。
在沒有負載的機器上,該命令基本上都是返回空的, 在負載很高的狀況下,可能意義也不是特別的大
> db.currentOp() { "inprog" : [ ] }
如下是一個有負載的機器上獲得的返回值樣例:
{ "opid" : "shard3:466404288", "active" : false, "waitingForLock" : false, "op" : "query", "ns" : "sd.usersEmails", "query" : { }, "client_s" : "10.121.13.8:34473", "desc" : "conn" },
字段名字都能自解釋。若是你發現一個操做太長,把數據庫卡死的話,能夠用這個命令殺死他
> db.killOp("shard3:466404288")