前言
說(shuō)到MongoDB的慢日志分析，就不得不提到profile分析器，profile分析器將記錄的慢日志寫(xiě)到system.profile集合下，這個(gè)集合是一個(gè)固定集合。我們可以通過(guò)對(duì)這個(gè)集合的查詢(xún)，來(lái)了解當(dāng)前的慢日志，進(jìn)而對(duì)數(shù)據(jù)庫(kù)進(jìn)行優(yōu)化。
整體環(huán)境
MongoDB 3.2.5
實(shí)戰(zhàn)
Part1:輸出示范
在查詢(xún)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)主要包含如下幾類(lèi)
- insert
- query
- update
- remove
- getmore
- command
代表了該慢日志的種類(lèi)是什么，是查詢(xún)、插入、更新、刪除還是其他。
system.profile.ns
該項(xiàng)表明該慢日志是哪個(gè)庫(kù)下的哪個(gè)集合所對(duì)應(yīng)的慢日志。
system.profile.query
該項(xiàng)詳細(xì)輸出了慢日志的具體語(yǔ)句和行為
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ù)庫(kù)不單單要?jiǎng)h除舊Key，還要插入新的Key到B-Tree索引中
system.profile.writeConflicts
寫(xiě)沖突發(fā)生的數(shù)量，例如update一個(gè)正在被別的update操作的文檔
system.profile.numYield
為了讓別的操作完成而屈服的次數(shù)，一般發(fā)生在需要訪問(wèn)的數(shù)據(jù)尚未被完全讀取到內(nèi)存中，MongoDB會(huì)優(yōu)先完成在內(nèi)存中的操作
system.profile.locks
在操作中產(chǎn)生的鎖，鎖的種類(lèi)有多種，如下：
| Global |
Represents global lock. |
| MMAPV1Journal |
Represents MMAPv1 storage engine specific lock to synchronize journal writes; for non-MMAPv1 storage engines, the mode forMMAPV1Journal is empty. |
| Database |
Represents database lock. |
| Collection |
Represents collection lock. |
| Metadata |
Represents metadata lock. |
| oplog |
Represents lock on the oplog. |
鎖的模式也有多種，如下：
| Lock Mode |
Description |
| R |
Represents Shared (S) lock. |
| W |
Represents Exclusive (X) lock. |
| r |
Represents Intent Shared (IS) lock. |
| w |
Represents Intent Exclusive (IX) lock. |
system.profile.locks.acquireCoun
在各種不用的種類(lèi)下，請(qǐng)求鎖的次數(shù)
system.profile.nreturned
該操作最終返回文檔的數(shù)量
system.profile.responseLength
結(jié)果返回的大小，單位為bytes，該值如果過(guò)大，則需考慮limit()等方式減少輸出結(jié)果
system.profile.millis
該操作從開(kāi)始到結(jié)束耗時(shí)多少，單位為毫秒
system.profile.execStats
包含了一些該操作的統(tǒng)計(jì)信息，只有query類(lèi)型的才會(huì)顯示
system.profile.execStats.stage
包含了該操作的詳細(xì)信息，例如是否用到索引
system.profile.ts
該操作執(zhí)行時(shí)的時(shí)間
system.profile.client
哪個(gè)客戶(hù)端發(fā)起的該操作，并顯示出該客戶(hù)端的ip或hostname
system.profile.allUsers
哪個(gè)認(rèn)證用戶(hù)執(zhí)行的該操作
system.profile.user
是否認(rèn)證用戶(hù)執(zhí)行該操作，如認(rèn)證后使用其他用戶(hù)操作，該項(xiàng)為空
總結(jié)
system.profile集合是定位慢SQL的手段之一，了解每一個(gè)輸出項(xiàng)的含義有助于我們更快的定位問(wèn)題。由于筆者的水平有限，編寫(xiě)時(shí)間也很倉(cāng)促，文中難免會(huì)出現(xiàn)一些錯(cuò)誤或者不準(zhǔn)確的地方，不妥之處懇請(qǐng)讀者批評(píng)指正。
好了，以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作能帶來(lái)一定的幫助，如果有疑問(wèn)大家可以留言交流，謝謝大家對(duì)腳本之家的支持。
您可能感興趣的文章:- MongoDB使用profile分析慢查詢(xún)的步驟
