在公司的項(xiàng)目中,突然出現(xiàn)過一個(gè)情況,mongodb 的CPU利用率到達(dá)100%,導(dǎo)致服務(wù)器這邊卡死了,請(qǐng)求了半天無響應(yīng),提示請(qǐng)求超時(shí)。
因?yàn)椋?dāng)時(shí)APP用戶可能會(huì)在某一個(gè)時(shí)間段集中的使用,所以,請(qǐng)求量一下子就飆上去了,剛好APP打開請(qǐng)求的時(shí)候,有一個(gè)mongodb的請(qǐng)求。
當(dāng)時(shí)因?yàn)镸ongodb的服務(wù)器不在我們這邊,所以一下子沒反應(yīng)過來,不過最后還是給排除出,并解決了。這里就來記錄下排查和解決的全過程。
問題分析:
1.根據(jù)代碼,定位到了是Mongodb的報(bào)錯(cuò)。
2.進(jìn)入Mongodb 服務(wù)器的監(jiān)控后臺(tái),這里是在阿里云購買的云緩存。
3.知道是Mongodb出問題,就好辦了,阿里云里面有個(gè)索引推薦,很好用的,會(huì)給出查詢時(shí)間,執(zhí)行次數(shù),和推薦策略
OK,這里準(zhǔn)備工作就基本做完了。
解決策略:
1.根據(jù)這些給出的執(zhí)行次數(shù),和執(zhí)行時(shí)間慢的,去看了下庫。從設(shè)計(jì)上,有問題,一個(gè)庫有900W的數(shù)據(jù),然后集合邏輯看了下,這庫只往里面存數(shù)據(jù),從不清理
2.沒有建立過索引,包括單一索引和連接索引,這也是會(huì)導(dǎo)致慢的一個(gè)原因。優(yōu)化后是這樣的,
db.getCollection('course_study_history').createIndex({'studentId':1,'contentStudyID':1,'courseWareID':1,'courseStudyId':1})
3.一個(gè)查詢總數(shù)的方法有問題,下面是修改后的JAVA方法:
MongoCollectionDocument> collection = database.getCollection(pushMessageCollection);
long cNt = collection.count(Filters.and(Filters.eq("userId", userId),
Filters.eq("sendType", sendType),
Filters.eq("message_read", "0")));
最開始的寫法,大概就類型,Mysql 里,查詢某個(gè)list,然后list.size(),得出總數(shù),
修改后的方法:大概就相當(dāng)于 count(id) 得出總數(shù),
這樣的話,修改后的方法,肯定就會(huì)比修改前的快。
方案基本決定下來了,實(shí)施后開始?jí)毫y(cè)試。
沒修改時(shí)的2000并發(fā):
修改后的2000并發(fā):
可以看到時(shí)間,也明顯的提高了。
并且測(cè)試4000 并發(fā),雖然慢了,不過沒崩掉。
再查看CPU信息,沒有出現(xiàn)100%的情況了。
以上就是本文的全部?jī)?nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
您可能感興趣的文章:- python連接mongodb數(shù)據(jù)庫操作數(shù)據(jù)示例
- 詳解linux 使用docker安裝mongodb方法
- Pycharm連接MongoDB數(shù)據(jù)庫安裝教程詳解
- 利用golang驅(qū)動(dòng)操作MongoDB數(shù)據(jù)庫的步驟
- SpringBoot整合MongoDB的示例
- SpringBoot配置MongoDB多數(shù)據(jù)源的方法步驟
- Spring Boot 整合 MongoDB的示例
- ubuntu安裝mongodb創(chuàng)建賬號(hào)和庫及添加坐標(biāo)索引的流程分析
- MongoDB查詢之高級(jí)操作詳解(多條件查詢、正則匹配查詢等)
- SpringBoot+MongoDB實(shí)現(xiàn)物流訂單系統(tǒng)的代碼
- Django集成MongoDB實(shí)現(xiàn)過程解析