深入講解MongoDB的慢日誌查詢（profile）
https://www.jb51.net/article/117441.htm
前言
說到MongoDB的慢日誌分析，就不得不提到profile分析器，profile分析器將記錄的慢日誌寫到system.profile集合下，這個集合是一個固定集合。我們可以通過對這個集合的查詢，來了解當前的慢日誌，進而對資料庫進行優化。
整體環境
MongoDB 3.2.5
實戰
Part1:輸出示範
在查詢system.profile的時候，我們能夠觀察到所有的操作，包括remove,update,find等等都會被記錄到system.profile集合中，該集合中包含了諸多資訊，如：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 |
: "test.c",
"acquireCount" : {
|
Part2:輸出解讀
system.profile.op
這一項主要包含如下幾類
- insert
- query
- update
- remove
- getmore
- command
代表了該慢日誌的種類是什麼，是查詢、插入、更新、刪除還是其他。
system.profile.ns
該項表明該慢日誌是哪個庫下的哪個集合所對應的慢日誌。
system.profile.query
該項詳細輸出了慢日誌的具體語句和行為
system.profile.keysExamined
該項表明為了找出最終結果MongoDB搜尋了多少個key
system.profile.docsExamined
該項表明為了找出最終結果MongoDB搜尋了多少個文件
system.profile.keyUpdates
該項表名有多少個index key在該操作中被更改，更改索引鍵也會有少量的效能消耗，因為資料庫不單單要刪除舊Key，還要插入新的Key到B-Tree索引中
system.profile.writeConflicts
寫衝突發生的數量，例如update一個正在被別的update操作的文件
system.profile.numYield
為了讓別的操作完成而屈服的次數，一般發生在需要訪問的資料尚未被完全讀取到記憶體中，MongoDB會優先完成在記憶體中的操作
system.profile.locks
在操作中產生的鎖，鎖的種類有多種，如下：
| 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
在各種不用的種類下，請求鎖的次數
system.profile.nreturned
該操作最終返回文件的數量
system.profile.responseLength
結果返回的大小，單位為bytes，該值如果過大，則需考慮limit()等方式減少輸出結果
system.profile.millis
該操作從開始到結束耗時多少，單位為毫秒
system.profile.execStats
包含了一些該操作的統計資訊，只有query型別的才會顯示
system.profile.execStats.stage
包含了該操作的詳細資訊，例如是否用到索引
system.profile.ts
該操作執行時的時間
system.profile.client
哪個客戶端發起的該操作，並顯示出該客戶端的ip或hostname
system.profile.allUsers
哪個認證使用者執行的該操作
system.profile.user
是否認證使用者執行該操作，如認證後使用其他使用者操作，該項為空
總結
system.profile集合是定位慢SQL的手段之一，瞭解每一個輸出項的含義有助於我們更快的定位問題。由於筆者的水平有限，編寫時間也很倉促，文中難免會出現一些錯誤或者不準確的地方，不妥之處懇請讀者批評指正。