MongoDB CPU 利用率高,怎麼破?

2021-09-23 17:45:45 字數 2830 閱讀 4090

經常有使用者諮詢「mongodb cpu 利用率很高,都快跑滿了」,應該怎麼辦?

遇到這個問題,99.9999% 的可能性是「使用者使用上不合理導致」,本文主要介紹從應用的角度如何排查 mongodb cpu 利用率高的問題

使用者可以通過 mongo shell 連線,並執行db.currentop()命令,能看到資料庫當前正在執行的操作,如下是該命令的乙個輸出示例,標識乙個正在執行的操作。重點關注幾個字段

這裡先要明確一下,通過 db.currentop() 檢視正在執行的操作,目的到底是什麼?

並不是說我們要將正在執行的操作都列出來,然後通過killop逐個乾掉;這一步的目的是要看一下,是否有「意料之外」的耗時請求正在執行。

比如你的業務平時 cpu 利用率不高,運維管理人員連到資料庫執行了一些需要全表掃瞄的操作,然後突然 cpu 利用率飆高,導致你的業務響應很慢,那麼就要重點關注下那些執行時間很長的操作。

一旦找到罪魁禍首,拿到對應請求的 opid,執行db.killop(opid)將對應的請求乾掉。

如果你的應用一上線,cpu利用率就很高,而且一直持續,通過db.currentop的結果也沒發現什麼異常請求,可以進入到 step2 進行更深入的分析。

mongodb 支援 profiling 功能,將請求的執**況記錄到同db下的system.profile集合裡,profiling 有3種模式

profiling 設定文件在這裡,多看官網文件

預設請求下,mongodb 的 profiling 功能是關閉,生產環境建議開啟,慢請求閾值可根據需要定製,如不確定,直接使用預設值100ms。

operationprofiling:

mode: slowop

slowopthresholdms: 100

檢視最近3條 慢請求, 代表按插入數序逆序

db.system.profile.find().sort().limit(3)

在開啟了慢請求 profiling 的情況下(mongodb 雲資料庫是預設開啟慢請求 profiling的),我們對慢請求的內容進行分析,來找出可優化的點,常見的包括。

profiling的結果輸出含義在這裡,多看官網文件

cpu殺手1:全表掃瞄

全集合(表)掃瞄collscan,當乙個查詢(或更新、刪除)請求需要全表掃瞄時,是非常耗cpu資源的,所以當你在system.profile集合 或者 日誌檔案發現collscan關鍵字時,就得注意了,很可能就是這些查詢吃掉了你的 cpu 資源;確認一下,如果這種請求比較頻繁,最好是針對查詢的字段建立索引來優化。

乙個查詢掃瞄了多少文件,可檢視system.profile裡的doc***amined的值,該值越大,請求cpu開銷越大。

關鍵字:collscan、 doc***amined

cpu殺手2:不合理的索引

有的時候,請求即使查詢走了索引,執行也很慢,通常是因為索引建立不太合理(或者是匹配的結果本身就很多,這樣即使走索引,請求開銷也不會優化很多)。

如下所示,假設某個集合的資料,x欄位的取值很少(假設只有1、2),而y欄位的取值很豐富。

......

......

要服務這樣的查詢

db.createindex(  )         效果不好,因為x相同取值太多

db.createindex( ) 效果不好,因為x相同取值太多

db.createindex( ) 效果好,因為y相同取值很少

db.createindex( ) 效果好,因為y相同取值少

至於 與 的區別,可參考mongodb索引原理 及 復合索引官方文件 自行理解。

乙個走索引的查詢,掃瞄了多少條索引,可檢視system.profile裡的key***amined字段,該值越大,cpu 開銷越大。

關鍵字:ixscan、key***amined

cpu殺手3:大量資料排序

當查詢請求裡包含排序的時候,如果排序無法通過索引滿足,mongodb 會在記憶體李結果進行排序,而排序這個動作本身是非常耗 cpu 資源的,優化的方法仍然是建立索引,對經常需要排序的字段,建立索引。

當你在system.profile集合 或者 日誌檔案發現sort關鍵字時,就可以考慮通過索引來優化排序。當請求包含排序階段時,system.profile裡的hassortstage欄位會為 true。

關鍵字:sort、hassortstage

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

經過上述2步,你發現整個資料庫的查詢非常合理,所有的請求都是高效的走了索引,基本沒有優化的空間了,那麼很可能是你機器的服務能力已經達到上限了,應該公升級配置了(或者通過 sharding 擴充套件)。

當然最好的情況時,提前對 mongodb 進行測試,了解在你的場景下,對應的服務能力上限,以便及時擴容、公升級,而不是到 cpu 資源用滿,業務已經完全撐不住的時候才去做評估。

MongoDB CPU 利用率高 請求慢

遇到這個問題,99.9999 的可能性是 使用者使用上不合理導致 本文主要介紹從應用的角度如何排查 mongodb cpu 利用率高的問題 step1 分析資料庫正在執行的請求 使用者可以通過 mongo shell 連線,並執行db.currentop 命令,能看到資料庫當前正在執行的操作,如下是...

cpu利用率 CPU利用率錯誤

cpu利用率 cpu利用率是每個人用來衡量處理器效能的指標。netflix的高階效能架構師布倫丹 格雷格 brendan gregg 在第16屆年度南加州linux expo scale 上稱其為 五分鐘公共服務公告 但 cpu卻是一種誤導性的衡量指標,說明處理器的實際繁忙程度。布倫丹在他的閃電演講...

記憶體利用率

記憶體利用率 有多個命令提供有關系統記憶體利用率的相關資訊。最流行的是free 和pmap。free命令 free 命令顯示可用的物理記憶體量,其中包括總物理記憶體量 已用物理記憶體量 可用物理記憶體量。它也為交換空間顯示同樣的統計資訊,還顯示核心使用的記憶體快取大小和緩衝區的大小。圖7 5 顯示了...