Q: 最近公司測試一個接口，數(shù)據(jù)庫采用Mongo
并發(fā)策略：并發(fā)400個用戶，每3秒加載5個用戶，持續(xù)運(yùn)行30分鐘
數(shù)據(jù)量：8000條左右

壓測結(jié)果發(fā)現(xiàn)：
TPS始終在5左右
而CPU高達(dá)99%，內(nèi)存使用情況也高達(dá)1.7G
網(wǎng)卡流量145K

請問這種情況，是哪里的性能出現(xiàn)問題？

A：你這個CPU和內(nèi)存監(jiān)控的得是web服務(wù)器 就是部署程序的機(jī)器。
1、嘗試查看出現(xiàn)這類情況時候數(shù)據(jù)庫process，看看是否是當(dāng)時進(jìn)程到達(dá)了所設(shè)置的進(jìn)程數(shù)上限。如果是則調(diào)整數(shù)據(jù)庫進(jìn)程數(shù)上限再測試
2、嘗試查看程序連接池設(shè)置的最大連接數(shù)，如果程序設(shè)置的最大連接數(shù)上限很小，調(diào)整上限在測試看看
進(jìn)程排隊(duì)是合理現(xiàn)象，但是需要在當(dāng)前硬件環(huán)境下，將其控制在可接受范圍內(nèi)。
如果經(jīng)過調(diào)整過數(shù)據(jù)庫進(jìn)程上限和最大連接數(shù)，仍然無法解決問題，找到你的腳本
假設(shè)你的腳本順序是（其中a,b,c代表的是程序模塊）
web_submit_data(a);
web_submit_data(b);
web_submit_data(c);
分別找出他們在analysis中的響應(yīng)時間，按照順序從第一個響應(yīng)時間長的系統(tǒng)模塊開始調(diào)優(yōu)，就是調(diào)整程序的算法或者SQL。假如響應(yīng)時間 b>c>a，那么就先調(diào)整b，之后再測試。因?yàn)橛锌赡苁怯捎赽排隊(duì)導(dǎo)致c無法正常執(zhí)行所以才響應(yīng)時間漫長的。
以上僅供參考，沒有用過mongodb，數(shù)據(jù)庫進(jìn)程數(shù)我參考的是oracle進(jìn)程數(shù)的調(diào)整。

Q: 1.先說下這個接口是做什么的？你寫還是查？
2.你說的CPU高是前段還是DB服務(wù)器？
3.你的服務(wù)器架構(gòu)啥樣？
這些最基本的要提供
A: 1.　接口是取數(shù)據(jù)GET操作
2.　CPU高是應(yīng)用服務(wù)器那臺機(jī)子的CPU高，數(shù)據(jù)庫沒有監(jiān)測
3.　服務(wù)器架構(gòu)采用nginx

A: 這個有幾種可能：
1.你的服務(wù)器出錯了，cpu很高，你可以查查日志
2.服務(wù)器處理能力很低，占用cpu很高，但是處理量很少
3.內(nèi)存發(fā)生泄露，或者內(nèi)存不能釋放，重復(fù)讀寫頻繁，導(dǎo)致內(nèi)存持續(xù)增大，cpu無法處理

總結(jié)

以上是生活随笔為你收集整理的压测过程中，CPU和内存占用率很高，案例简单分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。