前言

說到MongoDB的慢日志分析，就不得不提到profile分析器，profile分析器將記錄的慢日志寫到system.profile集合下，這個(gè)集合是一個(gè)固定集合。我們可以通過對這個(gè)集合的查詢，來了解當(dāng)前的慢日志，進(jìn)而對數(shù)據(jù)庫進(jìn)行優(yōu)化。

整體環(huán)境

MongoDB 3.2.5

實(shí)戰(zhàn)

Part1:輸出示范

在查詢system.profile的時(shí)候，我們能夠觀察到所有的操作，包括remove,update,find等等都會(huì)被記錄到system.profile集合中，該集合中包含了諸多信息，如：

{ "op" : "query", "ns" : "test.c", "query" : { "find" : "c", "filter" : {  "a" : 1 } }, "keysExamined" : 2, "docsExamined" : 2, "cursorExhausted" : true, "keyUpdates" : 0, "writeConflicts" : 0, "numYield" : 0, "locks" : { "Global" : {  "acquireCount" : {  "r" : NumberLong(2)  } }, "Database" : {  "acquireCount" : {  "r" : NumberLong(1)  } }, "Collection" : {  "acquireCount" : {  "r" : NumberLong(1)  } } }, "nreturned" : 2, "responseLength" : 108, "millis" : 0, "execStats" : { "stage" : "FETCH", "nReturned" : 2, "executionTimeMillisEstimate" : 0, "works" : 3, "advanced" : 2, "needTime" : 0, "needYield" : 0, "saveState" : 0, "restoreState" : 0, "isEOF" : 1, "invalidates" : 0, "docsExamined" : 2, "alreadyHasObj" : 0, "inputStage" : {  "stage" : "IXSCAN",  "nReturned" : 2,  "executionTimeMillisEstimate" : 0,  "works" : 3,  "advanced" : 2,  "needTime" : 0,  "needYield" : 0,  "saveState" : 0,  "restoreState" : 0,  "isEOF" : 1,  "invalidates" : 0,  "keyPattern" : {  "a" : 1  },  "indexName" : "a_1",  "isMultiKey" : false,  "isUnique" : false,  "isSparse" : false,  "isPartial" : false,  "indexVersion" : 1,  "direction" : "forward",  "indexBounds" : {  "a" : [  "[1.0, 1.0]"  ]  },  "keysExamined" : 2,  "dupsTested" : 0,  "dupsDropped" : 0,  "seenInvalidated" : 0 } }, "ts" : ISODate("2015-09-03T15:26:14.948Z"), "client" : "127.0.0.1", "allUsers" : [ ], "user" : ""}

Part2:輸出解讀

system.profile.op

這一項(xiàng)主要包含如下幾類

1. insert
2. query
3. update
4. remove
5. getmore
6. command

代表了該慢日志的種類是什么，是查詢、插入、更新、刪除還是其他。

system.profile.ns

該項(xiàng)表明該慢日志是哪個(gè)庫下的哪個(gè)集合所對應(yīng)的慢日志。

system.profile.query

該項(xiàng)詳細(xì)輸出了慢日志的具體語句和行為

system.profile.keysExamined

該項(xiàng)表明為了找出最終結(jié)果MongoDB搜索了多少個(gè)key

system.profile.docsExamined

該項(xiàng)表明為了找出最終結(jié)果MongoDB搜索了多少個(gè)文檔

system.profile.keyUpdates

該項(xiàng)表名有多少個(gè)index key在該操作中被更改，更改索引鍵也會(huì)有少量的性能消耗，因?yàn)閿?shù)據(jù)庫不單單要?jiǎng)h除舊Key，還要插入新的Key到B-Tree索引中

system.profile.writeConflicts

寫沖突發(fā)生的數(shù)量，例如update一個(gè)正在被別的update操作的文檔

system.profile.numYield

為了讓別的操作完成而屈服的次數(shù)，一般發(fā)生在需要訪問的數(shù)據(jù)尚未被完全讀取到內(nèi)存中，MongoDB會(huì)優(yōu)先完成在內(nèi)存中的操作

system.profile.locks

在操作中產(chǎn)生的鎖，鎖的種類有多種，如下：

鎖的模式也有多種，如下：

system.profile.locks.acquireCoun

在各種不用的種類下，請求鎖的次數(shù)

system.profile.nreturned

該操作最終返回文檔的數(shù)量

system.profile.responseLength

結(jié)果返回的大小，單位為bytes，該值如果過大，則需考慮limit()等方式減少輸出結(jié)果

system.profile.millis

該操作從開始到結(jié)束耗時(shí)多少，單位為毫秒

system.profile.execStats

包含了一些該操作的統(tǒng)計(jì)信息，只有query類型的才會(huì)顯示

system.profile.execStats.stage

包含了該操作的詳細(xì)信息，例如是否用到索引

system.profile.ts

該操作執(zhí)行時(shí)的時(shí)間

system.profile.client

哪個(gè)客戶端發(fā)起的該操作，并顯示出該客戶端的ip或hostname

system.profile.allUsers

哪個(gè)認(rèn)證用戶執(zhí)行的該操作

system.profile.user

是否認(rèn)證用戶執(zhí)行該操作，如認(rèn)證后使用其他用戶操作，該項(xiàng)為空

總結(jié)

system.profile集合是定位慢SQL的手段之一，了解每一個(gè)輸出項(xiàng)的含義有助于我們更快的定位問題。由于筆者的水平有限，編寫時(shí)間也很倉促，文中難免會(huì)出現(xiàn)一些錯(cuò)誤或者不準(zhǔn)確的地方，不妥之處懇請讀者批評(píng)指正。

好了，以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作能帶來一定的幫助，如果有疑問大家可以留言交流，謝謝大家對武林網(wǎng)的支持。