在公司的專案中，突然出現過一個情況，mongodb 的CPU利用率到達100%,導致伺服器這邊卡死了，請求了半天無響應，提示請求超時。

因為，當時APP使用者可能會在某一個時間段集中的使用，所以，請求量一下子就飆上去了，剛好APP開啟請求的時候，有一個mongodb的請求。

當時因為Mongodb的伺服器不在我們這邊，所以一下子沒反應過來，不過最後還是給排除出，並解決了。這裡就來記錄下排查和解決的全過程。

問題分析：

1.根據程式碼，定位到了是Mongodb的報錯。

2.進入Mongodb 伺服器的監控後臺，這裡是在阿里雲購買的雲快取。

3.知道是Mongodb出問題，就好辦了，阿里雲裡面有個索引推薦，很好用的，會給出查詢時間，執行次數，和推薦策略

OK，這裡準備工作就基本做完了。

解決策略：

1.根據這些給出的執行次數，和執行時間慢的，去看了下庫。從設計上，有問題，一個庫有900W的資料，然後集合邏輯看了下，這庫只往裡面存資料，從不清理

2.沒有建立過索引，包括單一索引和連線索引，這也是會導致慢的一個原因。優化後是這樣的，

db.getCollection('course_study_history').createIndex({'studentId':1,'contentStudyID':1,'courseWareID':1,'courseStudyId':1})

3.一個查詢總數的方法有問題，下面是修改後的JAVA方法：

MongoCollection<Document> collection = database.getCollection(pushMessageCollection);
 
long cNt = collection.count(Filters.and(Filters.eq("userId",userId),Filters.eq("sendType",sendType),Filters.eq("message_read","0")));

最開始的寫法，大概就型別，Mysql 裡，查詢某個list，然後list.size()，得出總數，

修改後的方法：大概就相當於 count(id) 得出總數，

這樣的話，修改後的方法，肯定就會比修改前的快。

方案基本決定下來了，實施後開始壓力測試。

沒修改時的2000併發：

修改後的2000併發：

可以看到時間，也明顯的提高了。

並且測試4000 併發,雖然慢了，不過沒崩掉。

再檢視CPU資訊,沒有出現100%的情況了。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支援我們。