來源:
https://www.cnblogs.com/yangxiaoyi/p/7504753.html
https://www.cnblogs.com/luo-mao/p/6278170.html
http://www.pianshen.com/article/134476742/
開啟慢日志
1.查看mongodb慢日志是否開起
use BJ_Rack;
db.getProfilingStatus();
發現沒有開戶慢日志
2.開啟慢日志，設置超過100毫秒的操作為慢操作
db.setProfilingLevel(1,100);
3.查看慢日志內容
db.system.profile.find().sort({$natural:-1})
得到50個比較慢的操作日志.
通過配置文件開啟:
operationProfiling:
mode: slowOp
slowOpThresholdMs： 100
查看當前操作
db.currentOp(true);
主要有以下信息：
- client – 請求是由哪個客戶端發起的
- opid – 操作的opid，有需要的話，可以通過 db.killOp(opid) 殺死操作
- secs_running/microsecs_running – 請求運行的時間，如果這個值特別大就非常值得注意
- query/ns: 對集合進行的具體操作
- lock*：鎖相關參數
慢請求分析 – 全表掃描 COLLSCAN
如果在日志中看到關鍵字 COLLSCAN，說明該查詢在進行全表掃描，通常這就是 CPU 異常飆高的主要原因。
4.1. 查看掃描文檔數
system.profile 里 docsExamined 的值顯示了本次查詢的掃描文檔數。
4.2. 解決辦法 – 添加索引
最好針對查詢語句建立索引：
db.col.createIndex({"title":1})
- 1
我們也可以在添加索引時增加傳入可選參數，例如，在生產環境我們通常不希望索引添加的操作阻塞其他數據庫操作，這時就需要務必添加 background 參數：
db.col.createIndex({"title":1}, {'background', true})
- 1
5. 慢請求分析 – 索引設置不合理
有的時候，請求即使查詢走了索引，執行也很慢，通常是因為索引建立不太合理或者匹配結果太多。
索引通常應該建立在區分度大的字段上。
在 system.profile 中，可以通過 keysExamined 字段查看查詢掃描了多少條索引，如果該值過大，要考慮建立新的索引或優化查詢了。
6. 慢請求分析 – 大量數據排序
當查詢請求里包含排序的時候，如果排序無法通過索引滿足，MongoDB 會在內存中對結果進行排序。
大家都知道，排序是非常消耗 CPU 的一項操作，最好在需要排序的字段上建立索引。
system.profile 中的 SORT 關鍵字反映了查詢需要排序。
7. 服務能力評估
有時 CPU 消耗過高僅僅是單純的因為服務器達到了上限。
如果上面的措施都無法讓 CPU 占用率下降到合理的指標內，就要考慮擴容、升級來提升服務能力的上限。
但切忌將這個方法作為首要考慮的解決方案，合理的設置索引，建立資源預警，而不是盲目提升配置或在業務已經達到上限時再考慮優化。
8. 參考資料
https://docs.mongodb.com/manual/reference/method/db.currentOp/
https://docs.mongodb.com/manual/tutorial/manage-the-database-profiler/
https://docs.mongodb.com/manual/reference/database-profiler/
https://docs.mongodb.com/v3.2/reference/method/db.collection.createIndex/index.html
https://docs.mongodb.com/v3.2/indexes/index.html
https://docs.mongodb.com/v3.2/tutorial/analyze-query-plan/
https://yq.aliyun.com/articles/73389
http://www.runoob.com/mongodb/mongodb-indexing.html