在高負載壓力下支付寶是如何做性能測試的(4)

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

　　調優后的圖如下：

　　2. fullgc頻繁觸發

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

　　由上圖可以看出fullgc的耗時非常長，在6~7s左右，這樣會嚴重影響應用的響應時間。經分析是因為cms比例過大，回收頻率較慢導致，調優方式：調小cms的回比例，盡早觸發cmsgc，避免觸發fullgc。調優后回收情況如下

　　可以看出cmsgc時間縮短了很多,優化后可以大大提高。從上面2個例子看出cms比例不是絕對的，需要根據應用的具體情況來看，比如應用創建的對象存活周期長，且對象較大，可以適當提高cms的回收比例。

　　3. 疑似內存泄露，先看下圖

　　分析：每次cmsgc沒有回收干凈，old區呈上升趨勢，疑似內存泄露

　　最終有可能導致OOM，這種情況就需要dump內存進行分析：

　　找到oom內存dump文件，具體的文件配置在jvm參數里：

　　-XX:HeapDumpPath=/home/admin/logs

　　-XX:ErrorFile=/home/admin/logs/hs_err_pid%p.log

　　借助工具：MAT，分析內存最大的對象。具體工具的使用這里就不再介紹。

原文轉自：http://www.infoq.com/cn/articles/performance-test-of-zhifubao