小記性能測試瓶頸挖掘與分析

通常按照以下思路分析系統的瓶頸，先看業務指標:響應時間、業務錯誤率、和 tps 是否知足目標。
若是其中有一個有異常,能夠先排除施壓機和外圍依賴系統是否有瓶頸,若是沒有,關注網 絡、db 的性能和鏈接數,最後關注系統自己的指標:
1. 硬件：磁盤是否寫滿、內存是否夠用、cpu的利用率、平均load值
2. 軟件： 操做系統版本、jdk版本、jboss容器以及應用依賴的其餘軟件版本
3. JVM內存管理和回收是否合理
4. 應用程序自己代碼

應用系統自己的瓶頸

應用系統負載分析：

• CPU使用率
• 內存使用率
• Load 通常cpu的使用率應低於50%,若是太高有可能程序的算法耗費太多cpu,或者 某些代碼塊進行不合理的佔用。Load值儘可能保持在cpuS+2 或者cpuS*2,其中 cpu 和 load 通常與併發數成正比
• 內存能夠經過 2 種方式來查看: 1) 當 vmstat 命令輸出的 si 和 so 值顯示爲非 0 值, 則表示剩餘可支配的物理內存已經嚴重不足,須要經過與磁盤交換內容來保持系統的 穩定 ; 因爲磁盤處理的速度遠遠小於內存,此時就會出現嚴重的性能降低 ;si 和 so的值越大,表示性能瓶頸越嚴重。2) 用工具監控內存的使用狀況,若是出現內存佔用一直上升的趨勢有可能系統內存佔滿的狀況
• 若是出現內存佔用一直上升的趨勢,有可能系統一直在建立新的線程,舊的線程沒有銷燬; 或者應用申請了堆外內存,一直沒有回收致使內存一直增加.

JVM 瓶頸分析:

1.Gc 頻率分析

對於 java 應用來講,太高的 GC 頻率也會在很大程度上下降應用的性能。即便採用了併發 收集的策略,GC 產生的停頓時間積累起來也是不可忽略的,特別是出現 cmsgc 失敗,致使 fullgc 時的場景。下面舉幾個例子進行說明:
Cmsgc 頻率太高,當在一段較短的時間區間內,cmsGC 值超出預料的大,那麼說明該 JAVA 應用在處理對象的策略上存在着一些問題,即過多過快地建立了長壽命週期的對象, 是須要改進的。或者 old 區大小分配或者回收比例設置得不合理,致使 cms 頻繁觸發,下 面看一張 gc 監控圖(藍色線表明 cmsgc)

由圖看出:cmsGC 很是頻繁,後經分析是由於 jvm 參數 -XX:CMSInitiatingOccupanc yFraction 設置爲 15,比例過小致使 cms 比較頻繁,這樣能夠擴大 cmsgc 佔 old 區的比例, 下降 cms 頻率注。調優後的圖以下:

2.fullgc 頻繁觸發

當採用 cms 併發回收算法,當 cmsgc 回收失敗時會致使 fullgc:
fullgc 的耗時很是長,在 6~7s 左右,這樣會嚴重影響應用的響應時間。
經分析是由於 cms 比例過大,回收頻率較慢致使,調優方式:調小 cms 的回比例,儘早觸 發 cmsgc,避免觸發 fullgc
從上面 2 個例子看出 cms 比例不 是絕對的,須要根據應用的具體狀況來看,好比應用建立的對象存活週期長,且對象較大, 能夠適當提升 cms 的回收比例。

3.疑似內存泄露

分析:每次 cmsgc 沒有回收乾淨,old 區呈上升趨勢,疑似內存泄露
最終有可能致使 OOM,這種狀況就須要 dump 內存進行分析:
a.找到 oom 內存 dump 文件,具體的文件配置在 jvm 參數裏: -XX:HeapDumpPath=/ home/admin/logs
b.-XX:ErrorFile=/home/admin/logs/hs_err_pid%p.log
c.藉助工具:MAT,分析內存最大的對象