性能測試--壓測中問題定位思路


1、 剛開始壓測報錯,停了之后重新壓測不報錯
這種情況經常遇到,特別是重啟服務之后,因為系統剛重啟,需要做一些初始化的動作,如果一下上很多並發用戶數難免會報錯,只要壓測幾次之后不再報錯,就是正常的,服務器也需要“預熱”一段時間。

2、 少用戶並發不報錯,大用戶並發報錯
可能有兩種情況引起這種問題,一是腳本的問題:參數設置不夠或者錯誤;二是連接池設置的不合理。一定要先排除腳本的問題之后,再去查找其他問題,不要給開發人員帶來不必要的麻煩。

3、 服務器資源利用率高
服務器資源利用最常見的是CPU利用率高,內存利用率高常見於數據庫服務器,應用服務器的內存一般會在長時間壓測時出現問題。I/O一般常見磁盤被用完的情況,對於應用服務器可能是有大量的日志讀寫,對於數據庫服務器可能是表空間增長過大,磁盤空間不足。這里主要是分析CPU利用率高的問題,分別對數據庫CPU利用率高和應用服務器利用率高的情況進行說明。

4、 數據庫服務器CPU利用率高
數據庫CPU利用率高一般是大量的邏輯讀或者物理讀引起的,也有可能是解析比較復雜的SQL,如果是Oracle 數據庫,可以通過抓取AWR報告進行,重點看下面兩項:
SQL ordered by Gets
SQL ordered by Physical Reads (UnOptimized)

 

 

 

 

 

 



這一部分,通過Buffer Gets對SQL語句進行排序,即通過它執行了多少個邏輯I/O來排序。頂端的注釋表明一個PL/SQL單元的緩存獲得(Buffer Gets)包括被這個代碼塊執行的所有SQL語句的Buffer Gets。大量的邏輯讀往往伴隨着較高的CPU消耗,在這里的Buffer Gets是一個累積值,所以這個值大並不一定意味着這條語句的性能存在問題。通常我們可以通過對比該條語句的Buffer Gets和physical reads值,如果這兩個比較接近,肯定這條語句是存在問題的 ,如果對比差別不大,可以關注 **gets per exec的值,這個值如果太大,表明這條語句可能使用了一個比較差的索引或者使用了不當的表連接。
另外還可以通過查看使用CPU高的進程ID,根據進程ID查找對應的SQL ID,從而找出相應的sql語句。


5、 應用服務器CPU利用率高
針對應用服務器CPU利用率高有一個固定的定位問題思路:
使用top命令查看占用CPU最高的進程號

 

 

查看進程下所有線程信息,可以使用top,也可以使用ps命令
top -p pid -H
-p 表示進程PID
-c 顯示進程的絕對路徑
-H 顯示進程的所有線程

 

 

也可以用下面的命令將 cpu 占用率高的線程找出來:
ps H -eo user,pid,ppid,tid,time,%cpu,cmd --sort=%cpu

 

 

找到了占用cpu最高的兩個線程,要查看線程的信息, 把上面的進程信息dump下來,然后在文件查找線程信息,不是直接dump線程信息。線程對應的是棧,在棧中可以看到線程操作了哪些數據。
注意,有時候需要把線程號轉成16進制,因為dunmp的線程號可能是以16進程顯示的,比如:nid=0xc46e,0x表示是16進制的數據,c46e是線程號,轉成十進制是142156,則對應的線程號是142156。

 

 

6、響應時間慢

響應時間慢可以從兩個方面來分析,一是查看AWR報告,或者在數據庫中搜索慢的sql,在AWR報告中需要關注下面兩項:
SQL ordered by Elapsed Time
SQL ordered by CPU Time
一般sql的慢是沒加索引或者索引失效引起的,也有可能是查詢方式過於復雜,表的關聯關系不對,小表驅動大表,或者在sql語句中進行了大量的計算,具體的問題需要DBA或者開發人員進行分析。
如果不是慢sql引起的,則需要查找程序的問題,可以通過壓測工具定位到具體方法,也可以dump進程,查看是否有鎖爭用、死鎖或者資源等待的情況。在本次壓測中出現了大量dubbo服務等待數據庫響應的線程,數據庫的CPU利用率達到90%,導致應用的大部分進程是sleeping狀態,通過查看dump下來的線程發現大部分處於Runable狀態,而他們都在等待鎖住同一資源(數據庫)。增加數據庫CPU之后,響應時間慢的問題得到解決。

 

7、穩定性壓測出現內存泄露
本次穩定性壓測過程中出現了內存泄露的情況,具體引起的原因還在分析,但問題已經定位到。穩定壓測的前20小時之內,系統很穩定,20小時之后,出現了大量的報錯,並且報錯信息一直增加,部分交易響應時間達到二十幾秒,數據庫服務器幾乎沒有壓力,查看weblogic進程,幾乎沒有工作(占用的cpu資源0.5%左右),但有一個java進程CPU使用率很高:

 

 

懷疑是內存泄露,於是查看jvm內存回收情況:jstat -gcutil 10366 2000

 

 每2秒查看一次10366進程的內存回收情況,幾乎是一秒2次,並且伊甸園區和年老代的內存已經使用完畢,即使1秒回收2次也不能釋放,肯定有不能回收的大對象存在。下面就使用jmap工具,dump 將內存使用的詳細情況輸出到文件
jmap -dump:live,format=b,file=a.log pid
dump下來的文件大概2個G,使用工具(IBM HeapAnalyzer 工具 )進行分析。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM