在高负载压力下支付宝是如何做性能测试的(4)

发表于:2014-06-13来源:infoq作者:付丽华 孙玉星点击数: 标签:支付宝
由图看出:cmsGC非常频繁,后经分析是因为jvm参数-XX:CMSInitiatingOccupancyFraction设置为15,比例太小导致cms比较频繁,这样可以扩大cmsgc占old区的比例,降低c

  由图看出: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