更多深度文章,請關(guān)注云計(jì)算頻道：https://yq.aliyun.com/cloud

經(jīng)常有用戶咨詢「MongoDB CPU 利用率很高,都快跑滿了」,應(yīng)該怎么辦?

遇到這個問題,99.9999% 的可能性是「用戶使用上不合理導(dǎo)致」,本文主要介紹從應(yīng)用的角度如何排查 MongoDB CPU 利用率高的問題

Step1: 分析數(shù)據(jù)庫正在執(zhí)行的哀求

用戶可以通過 Mongo Shell 連接,并執(zhí)行 db.currentOp() 命令,能看到數(shù)據(jù)庫當(dāng)前正在執(zhí)行的操作,如下是該命令的一個輸出示例,標(biāo)識一個正在執(zhí)行的操作.重點(diǎn)關(guān)注幾個字段

• client：哀求是由哪個客戶端發(fā)起的?

• opid：操作的opid,有必要的話,可以通過 db.killOp(opid) 直接干掉的操作

• secs_running/microsecs_running： 這個值重點(diǎn)關(guān)注,代表哀求運(yùn)行的時間,如果這個值特別大,就得注意了,看看哀求是否合理

• query/ns: 這個能看出是對哪個集合正在執(zhí)行什么操作

• lock*：還有一些跟鎖相關(guān)的參數(shù),必要了解可以看官網(wǎng)文檔,本文不做詳細(xì)介紹

db.currentOp 文檔在這里,多看官網(wǎng)文檔

 { "desc" : "conn632530", "threadId" : "140298196924160", "connectionId" : 632530, "client" : "11.192.159.236:57052", "active" : true, "opid" : 1008837885, "secs_running" : 0, "microsecs_running" : NumberLong(70), "op" : "update", "ns" : "mygame.players", "query" : { "uid" : NumberLong(31577677)

這里先要明確一下,通過 db.currentOp() 查看正在執(zhí)行的操作,目的到底是什么?

并不是說我們要將正在執(zhí)行的操作都列出來,然后通過 killOp 逐個干掉；這一步的目的是要看一下,是否有「意料之外」的耗時哀求正在執(zhí)行.

好比你的業(yè)務(wù)平時 CPU 利用率不高,運(yùn)維管理人員連到數(shù)據(jù)庫執(zhí)行了一些需要全表掃描的操作,然后突然 CPU 利用率飆高,導(dǎo)致你的業(yè)務(wù)響應(yīng)很慢,那么就要重點(diǎn)關(guān)注下那些執(zhí)行時間很長的操作.

一旦找到罪魁禍?zhǔn)?拿到對應(yīng)哀求的 opid,執(zhí)行 db.killOp(opid) 將對應(yīng)的哀求干掉.

如果你的應(yīng)用一上線,cpu利用率就很高,而且一直持續(xù),通過 db.currentOp 的結(jié)果也沒發(fā)現(xiàn)什么異常哀求,可以進(jìn)入到 Step2 進(jìn)行更深入的分析.

Step2：分析數(shù)據(jù)庫慢哀求

MongoDB 支持 profiling 功能,將哀求的執(zhí)行情況記錄到同DB下的 system.profile 集合里,profiling 有3種模式

profiling 設(shè)置文檔在這里,多看官網(wǎng)文檔

• 關(guān)閉 profiling

• 針對所有哀求開啟 profiling,將所有哀求的執(zhí)行都記錄到 system.profile 集合

• 針對慢哀求 profiling,將超過一定閾值的哀求,記錄到system.profile 集合

默認(rèn)哀求下,MongoDB 的 profiling 功能是關(guān)閉,生產(chǎn)環(huán)境建議開啟,慢哀求閾值可根據(jù)需要定制,如不確定,直接使用默認(rèn)值100ms.

operationProfiling： mode: slowOp

基于上述配置,MongoDB 會將超過 100ms 的哀求記錄到對應(yīng)DB 的 system.profile 集合里,system.profile 默認(rèn)是一個最多占用 1MB 空間的 capped collection.

查看最近3條 慢哀求,{$natrual: -1} 代表按插入數(shù)序逆序

在開啟了慢哀求 profiling 的情況下(MongoDB 云數(shù)據(jù)庫是默認(rèn)開啟慢哀求 profiling的),我們對慢哀求的內(nèi)容進(jìn)行分析,來找出可優(yōu)化的點(diǎn),常見的包括.

profiling的結(jié)果輸出含義在這里,多看官網(wǎng)文檔

CPU殺手1：全表掃描

全集合(表)掃描 COLLSCAN,當(dāng)一個查詢(或更新、刪除)哀求需要全表掃描時,是非常耗CPU資源的,所以當(dāng)你在 system.profile 集合 或者 日志文件發(fā)現(xiàn) COLLSCAN 關(guān)鍵字時,就得注意了,很可能就是這些查詢吃掉了你的 CPU 資源；確認(rèn)一下,如果這種哀求比較頻繁,最好是針對查詢的字段建立索引來優(yōu)化.

一個查詢掃描了多少文檔,可查看 system.profile 里的 docsExamined 的值,該值越大,哀求CPU開銷越大.

關(guān)鍵字：COLLSCAN、 docsExamined

CPU殺手2：不合理的索引

有的時候,哀求即使查詢走了索引,執(zhí)行也很慢,通常是因?yàn)楹侠斫⒉惶侠?或者是匹配的結(jié)果本身就很多,這樣即使走索引,哀求開銷也不會優(yōu)化很多).

如下所示,假設(shè)某個集合的數(shù)據(jù),x字段的取值很少(假設(shè)只有1、2),而y字段的取值很豐富.

{ x: 1, y: 1 }

要服務(wù) {x: 1: y: 2} 這樣的查詢

db.createIndex( {x: 1} ) 效果欠好,因?yàn)閤相同取值太多db.createIndex( {x: 1, y: 1} ) 效果欠好,因?yàn)閤相同取值太多db.createIndex( {y: 1 } ) 效果好,因?yàn)閥相同取值很少db.createIndex( {y: 1, x: 1 } ) 效果好,因?yàn)閥相同取值少

至于{y: 1} 與 {y: 1, x: 1} 的區(qū)別,可參考MongoDB索引原理 及 復(fù)合索引官方文檔 自行理解.

一個走索引的查詢,掃描了多少條索引,可查看 system.profile 里的 keysExamined 字段,該值越大,CPU 開銷越大.

關(guān)鍵字：IXSCAN、keysExamined

CPU殺手3：大量數(shù)據(jù)排序

當(dāng)查詢哀求里包含排序的時候,如果排序無法通過索引滿足,MongoDB 會在內(nèi)存李結(jié)果進(jìn)行排序,而排序這個動作本身是非常耗 CPU 資源的,優(yōu)化的方法仍然是建立索引,對經(jīng)常需要排序的字段,建立索引.

當(dāng)你在 system.profile 集合 或者 日志文件發(fā)現(xiàn) SORT 關(guān)鍵字時,就可以考慮通過索引來優(yōu)化排序.當(dāng)哀求包含排序階段時, system.profile 里的 hasSortStage 字段會為 true.

關(guān)鍵字：SORT、hasSortStage

其他還有諸如建索引,aggregationv等操作也可能非常耗 CPU 資源,但本色上也是上述幾種場景；建索引需要全表掃描,而vaggeregation 也是遍歷、查詢、更新、排序等動作的組合.

Step3: 服務(wù)才能評估

經(jīng)過上述2步,你發(fā)現(xiàn)整個數(shù)據(jù)庫的查詢非常合理,所有的哀求都是高效的走了索引,基本沒有優(yōu)化的空間了,那么很可能是你機(jī)器的服務(wù)能力已經(jīng)達(dá)到上限了,應(yīng)該升級配置了(或者通過 sharding 擴(kuò)展).

當(dāng)然最好的情況時,提前對 MongoDB 進(jìn)行測試,了解在你的場景下,對應(yīng)的服務(wù)才能上限,以便及時擴(kuò)容、升級,而不是到 CPU 資源用滿,業(yè)務(wù)已經(jīng)完全撐不住的時候才去做評估.