在高负载压力下支付宝是如何做性能测试的(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