效能壓測過程中遇到的效能問題及解決辦法
一、測試過程中cpu過高
1、用vmstat實時監控cpu使用情況。很小的壓力AP cpu卻到了80%多,指標是不能超過60%。
vmstat 2(每二秒顯示一次系統記憶體的統計資訊)
2、分析是use cpu過高還是sys cpu過高,常見的是use cpu使用過高。
3、如果是sys cpu使用過高,先把消耗cpu最多的程序找出來(top命令),再找到該執行緒下消耗cpu過高的是哪幾個執行緒,再把該執行緒轉換成16進位制,再用jstack命令來dump執行緒棧,看這個執行緒棧在呼叫什麼東西導致use cpu過高。
①top->top -H -p pid->②
printf '0x%x' tid->③stack pid | grep tid->④
jstackpid > dump01
二、記憶體溢位(堆溢位、棧溢位、持久代溢位)
1、堆記憶體溢位
1)穩定性壓測一段時間後報錯,日誌報java.lang.OutOfMemoryError.Java heap space。
2)用jmap -histo pid | head -20命令dump堆記憶體使用情況,檢視堆記憶體排名前20個物件,看是否有自己應用程式的方法,從最高的查起,如果有則檢查該方法是什麼原因造成堆記憶體溢位。
3)如果前20裡沒有自己的方法,則用jmap -dump來dump堆記憶體(jmap -dump:format=b,file=202007028.dump 105944),在用jvisualvm分析dump下來的堆記憶體,分析匯出記憶體溢位的方法。
4)如果應用程式的方法沒有問題,則需要修改JVM引數,修改xms,xmx,調整堆記憶體引數,一般是增加堆記憶體。
2、棧記憶體溢位
1)穩定性壓測一段時間後報錯,日誌報Java.Lang.StackOverflowError。
2)修改jvm引數,將xss引數改大,增加棧記憶體。
3)棧溢位一定是做批量操作引起的,減少批處理資料量。
3、持久代溢位
1)穩定性壓測一定時間後,日誌報Java.Lang.OutOfMenoryError.PermGen Space。
2)這種原因是由於類、方法描述、欄位描述、常量池、訪問修飾符等一些靜態變數太多,將持久代佔滿導致持久代溢位。
3)修改jvm配置,將XX:MaxPermSize=256引數調大。儘量減少靜態變數。
三、執行緒死鎖
1、容量測試壓測一段時間後,壓力工具報連線超時。
2、造成這種現象的原因很多,比如頻寬不夠,中介軟體執行緒池不夠用,資料庫連線池不夠,連線數佔滿等都會造成連線不上而報超時錯誤。
3、jstack命令dump執行緒棧,搜尋執行緒棧裡有沒有block,如果有的話就是執行緒死鎖,找到死鎖的執行緒,分析對應的程式碼。
四、資料庫死鎖
1、容量測試壓測一段時間後,報連線超時。
2、造成這種現象的原因很多,比如頻寬不夠,中介軟體執行緒池不夠用,資料庫連線池不夠,連線數佔滿等都會造成連線不上而報超時錯誤。
3、資料庫日誌中搜索block,能搜到block的話就是存在資料庫死鎖,找到日誌,檢視對應的sql,優化造成死鎖的sql。
五、資料庫連線池不釋放
1、容量測試壓測一段時間後,報連線超時。
2、造成這種現象的原因很多,比如頻寬不夠,中介軟體執行緒池不夠用,資料庫連線池不夠,連線數佔滿等都會造成連線不上而報超時錯誤。
3、去資料庫檢視應用程式到資料庫的連線有多少個( show full processlist),假如應用程式裡面配置的資料庫連線為30,在資料庫檢視應用程式到資料庫的連線也是30,則表示連線池佔滿了。將配置改成90試試,去資料庫看如果連線到了90,則可以確定是資料庫連線池不釋放導致的。檢視程式碼,資料庫連線部分是不是有建立連線但是沒有關閉連線的情況。基本就是這種情況導致的,修改程式碼即可。
六、TPS上不去
1、壓力大的時候tps頻繁抖動,導致總tps上不去。檢視是否有fullgc(tail -f gc_mSrv1.log | grep full)。
2、pacing設定太小也會導致tps上不去,對抖動大的交易多增加點使用者即可。
3、tps抖動,單壓抖動大的交易,發現很平穩,這時懷疑是不是壓力太大導致,所以發容量的時候把壓力最大的那隻交易分到其他壓力機,然後發現tps不抖動了。注意:多臺壓力機隻影響tps抖動,不會影響伺服器的cpu。
4、看響應時間有沒有超時,看使用者數夠不夠。
七、伺服器壓力不均衡(相差1%-2%是正常的)
1、跑最優容量的時候,四臺AP只有一臺cpu超過60%,其他三臺都在60%以下。
2、檢視伺服器是否有定時任務。
3、檢視是否存在壓力機瓶頸。
4、是否存在頻寬瓶頸(區域網不存在此問題)。
5、檢視部署的版本,配置是否一樣。
6、可能別人也在用這些AP,因為同一臺物理機上有很多虛擬機器,因為別人先用,資源被別人先佔了。
八、fullgc時間太長
1、跑容量和穩定性的時候,出現報請求超時錯誤,檢視後臺日誌是fullgc了,看幾點報的錯和日誌裡fullgc的時間是否對應,fullgc會暫停整個應用程式,導致LR前端沒響應,所以報錯,這時可以減少old代記憶體,從而減少fullgc時間,減少fullgc時間就不會報錯,讓使用者幾乎感覺不到應用程式暫停。
2、四臺AP輪流著full gc(部分server fullgc,其他server也會fullgc),這時可以制定策略讓不同的server不同時fullgc,或者等夜間交易量少時寫定時任務重啟服務。