在公司的項(xiàng)目中，突然出現(xiàn)過(guò)一個(gè)情況，mongodb 的CPU利用率到達(dá)100%,導(dǎo)致服務(wù)器這邊卡死了，請(qǐng)求了半天無(wú)響應(yīng)，提示請(qǐng)求超時(shí)。

因?yàn)?，?dāng)時(shí)APP用戶(hù)可能會(huì)在某一個(gè)時(shí)間段集中的使用，所以，請(qǐng)求量一下子就飆上去了，剛好APP打開(kāi)請(qǐng)求的時(shí)候，有一個(gè)mongodb的請(qǐng)求。

當(dāng)時(shí)因?yàn)镸ongodb的服務(wù)器不在我們這邊，所以一下子沒(méi)反應(yīng)過(guò)來(lái)，不過(guò)最后還是給排除出，并解決了。這里就來(lái)記錄下排查和解決的全過(guò)程。

問(wèn)題分析：

1.根據(jù)代碼，定位到了是Mongodb的報(bào)錯(cuò)。

2.進(jìn)入Mongodb 服務(wù)器的監(jiān)控后臺(tái)，這里是在阿里云購(gòu)買(mǎi)的云緩存。

3.知道是Mongodb出問(wèn)題，就好辦了，阿里云里面有個(gè)索引推薦，很好用的，會(huì)給出查詢(xún)時(shí)間，執(zhí)行次數(shù)，和推薦策略

OK，這里準(zhǔn)備工作就基本做完了。

解決策略：

1.根據(jù)這些給出的執(zhí)行次數(shù)，和執(zhí)行時(shí)間慢的，去看了下庫(kù)。從設(shè)計(jì)上，有問(wèn)題，一個(gè)庫(kù)有900W的數(shù)據(jù)，然后集合邏輯看了下，這庫(kù)只往里面存數(shù)據(jù)，從不清理

2.沒(méi)有建立過(guò)索引，包括單一索引和連接索引，這也是會(huì)導(dǎo)致慢的一個(gè)原因。優(yōu)化后是這樣的，

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

3.一個(gè)查詢(xún)總數(shù)的方法有問(wèn)題，下面是修改后的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")));

最開(kāi)始的寫(xiě)法，大概就類(lèi)型，Mysql 里，查詢(xún)某個(gè)list，然后list.size()，得出總數(shù)，

修改后的方法：大概就相當(dāng)于 count(id) 得出總數(shù)，

這樣的話，修改后的方法，肯定就會(huì)比修改前的快。

方案基本決定下來(lái)了，實(shí)施后開(kāi)始?jí)毫y(cè)試。

沒(méi)修改時(shí)的2000并發(fā)：

修改后的2000并發(fā)：

可以看到時(shí)間，也明顯的提高了。

并且測(cè)試4000 并發(fā),雖然慢了，不過(guò)沒(méi)崩掉。

再查看CPU信息,沒(méi)有出現(xiàn)100%的情況了。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。