支付寶的性能測試(3)

　　Jvm可以通過jdk自帶的jconsole或者jvisualvm來監控。

　　總體來說，監控了這些指標，對系統的性能就有了掌握，同樣這樣指標也可以反饋系統的瓶頸所在。

　　四.性能測試瓶頸挖掘與分析

　　我們在上面一章中拿到性能測試結果，這么多數據，怎么去分析系統的瓶頸在哪里呢，一般是按照這樣的思路，先看業務指標：響應時間、業務錯誤率、和tps是否滿足目標。

　　如果其中有一個有異常，可以先排除施壓機和外圍依賴系統是否有瓶頸，如果沒有，關注網絡、db的性能和連接數，最后關注系統本身的指標：

　　硬件：磁盤是否寫滿、內存是否夠用、cpu的利用率、平均load值

　　軟件：操作系統版本、jdk版本、jboss容器以及應用依賴的其他軟件版本

　　Jvm內存管理和回收是否合理

　　應用程序本身代碼

　　先看下圖：是一般性能測試環境部署圖

　　我們在定位的時候，可按照標注中的1、2、3數字依次進行排查，先排查施壓機是否有瓶頸、接著看后端依賴系統、db、網絡等，最后看被壓機本身，例如響應時間逐漸變慢，一般來說是外圍依賴的系統出現的瓶頸導致整體響應變慢。下面針對應用系統本身做下詳細的分析，針對常見問題舉1~2個例子：

　　4.1 應用系統本身的瓶頸

　　1. 應用系統負載分析：

　　服務器負載瓶頸經常表現為，服務器受到的并發壓力比較低的情況下，服務器的資源使用率比預期要高，甚至高很多。導致服務器處理能力嚴重下降，最終有可能導致服務器宕機。實際性能測試工作中，經常會用以下三類資源指標判定是否存在服務器負載瓶頸：

　　1.CPU使用率

　　2,內存使用率

　　3.Load

　　一般cup的使用率應低于50%，如果過高有可能程序的算法耗費太多cpu，或者某些代碼塊進行不合理的占用。Load值盡量保持在cpuS+2 或者cpuS*2，其中cpu和load一般與并發數成正比(如下圖)

　　內存可以通過2種方式來查看：

　　1) 當vmstat命令輸出的si和so值顯示為非0值，則表示剩余可支配的物理內存已經嚴重不足，需要通過與磁盤交換內容來保持系統的穩定;由于磁盤處理的速度遠遠小于內存，此時就會出現嚴重的性能下降;si和so的值越大，表示性能瓶頸越嚴重。

　　2) 用工具監控內存的使用情況，如果出現下圖的增長趨勢(used曲線呈線性增長)，有可能系統內存占滿的情況：

　　如果出現內存占用一直上升的趨勢，有可能系統一直在創建新的線程，舊的線程沒有銷毀;或者應用申請了堆外內存，一直沒有回收導致內存一直增長。

　　4.2 Jvm瓶頸分析

　　4.2.1Gc頻率分析

　　對于java應用來說，過高的GC頻率也會在很大程度上降低應用的性能。即使采用了并發收集的策略，GC產生的停頓時間積累起來也是不可忽略的，特別是出現cmsgc失敗，導致fullgc時的場景。下面舉幾個例子進行說明：

　　1. Cmsgc頻率過高，當在一段較短的時間區間內，cmsGC值超出預料的大，那么說明該JAVA應用在處理對象的策略上存在著一些問題，即過多過快地創建了長壽命周期的對象，是需要改進的?；蛘遫ld區大小分配或者回收比例設置得不合理，導致cms頻繁觸發，下面看一張gc監控圖(藍色線代表cmsgc)

　　由圖看出：cmsGC非常頻繁，后經分析是因為jvm參數-XX:CMSInitiatingOccupancyFraction設置為15，比例太小導致cms比較頻繁，這樣可以擴大cmsgc占old區的比例，降低cms頻率注。

　　調優后的圖如下：

　　2. fullgc頻繁觸發

　　當采用cms并發回收算法，當cmsgc回收失敗時會導致fullgc：

原文轉自：http://www.uml.org.cn/Test/201406112.asp?artid=1785

• 共4頁:
• 上一頁
• 1
• 2
• 3
• 4
• 下一頁