loadrunner分析内存泄露.docVIP

又见内存泄露1、首先是测试人员使用Loadrunner测试的过程中发现系统的吞吐率会随着时间而下降，在排除了测试数据分布不均的问题在测试，发现吞吐率保持稳定的一段时间后会陡然下降，平均事务处理时间陡然上升。于是，对系统的运行进行监控，在客户端压力平均的时候，系统内存两个小时内从500m上升到1G，基本上可以认定是内存泄露。1.1系统的吞吐率图 下载 (40.49 KB) 2009-6-21 19:04 1.2系统的平均事务处理时间图 下载 (33 KB) 2009-6-21 19:04 2、添加 verbose:gc启动的参数，重新测试，发现每次Full GC后的对象空间持续缓慢增加，过了一段时间后，发现Miner GC无法释放空间，每次GC都是Full GC，到最后，Full GC也无法释放出空间出来。3、安装netbean profile对系统使用情形进行监控，发现a、堆内存的已使用空间缓慢增长，直到最大内存限制； 下载 (16.74 KB) 2009-6-21 19:04 b、接近最大内存限制的时候，内存平均对象的年龄（Surviving Generations）急剧上升，见下图中的红线。c、Relative Time Spendt in GC 直剧上升，分析，当GC占用的CPU大量时间，系统的吞吐率下降，和LoadRunner的测试结果是符合的。见下图中的蓝线 下载 (20.95 KB) 2009-6-21 19:04 4、获取内存对象的静态映像，发现内存中占空间最大的几种存活对象的平均对象年龄都比较大，并且随着时间的增长，这几类对象占用的空间与平均对象年龄都不停的加大，见图。 下载 (42.22 KB) 2009-6-21 19:04 5、查看这几种对象的分配时候的程序堆栈，发现这些对象是mule框架初始化组件对象的时候所创建，心中犯疑，什么促使mule框架不停的创建全局对象？追踪了几条对象生成的路径，发现不断增长的对象似乎都是 org.mule.providers.soap.xfire.transport.MuleLocalTransport产生的，例如，19m的 HashMap$Entry[]由MuleLocalTransport的父类 org.codehaus.xfire.transport.AbstractTransport构造的时候产生，17m的 HashMap$Entry[]由MuleLocalTransport的createNewChannel的方法生成。每调用 createNewChannel一次就会生成一个全局对象 org.codehaus.xfire.transport.DefaultEndpoint。而MuleLocalTransport对象只有在初始化的时候才会生成全局对象。继续看代码发现可以在XFireServiceComponent的setDescriptor打印日志来确认mule是否不停创建全局对象。6、在XFireServiceComponent的关键初始化方法setDescriptor中添加日志，编译、重新打包，替换原来的类。新的类每当 setDescriptor被调用一次就打印一行日志。重新测试，发现每个一段时间setDescriptor就被调用一次。由于每调用 setDescriptor一次，就会产生大量的全局对象，并且全局对象不被释放，导致堆内存的增长。7、会让mule如此疯狂的原因是什么呢？详细查看mule的配置，逐步集中到对象池与线程池的配置：发现对象池的配置maxActive=5，maxIdle=5 pooling-profile maxactive=5 maxidle=5 exhaustedaction=GROW maxwait=1000，配置明显过小，在对象池的exhaustedAction=GROW 。线程池的配置maxThreadsActive明显大于对象池的配置。这样mule肯定会创建对象，由于/pooling- profile 对象池的对象很快由于超过了maxActive=5，多余的对象会被释放。pooling-profile maxactive=5 maxidle=5 exhaustedaction=GROW maxwait=10008、修改该配置maxActive=50，maxIdle=50，/pooling-profile 对象池的exhaustedAction=Wait， pooling-profile maxactive=5 maxidle=5 exhaustedaction=GROW maxwait=1000重新运行，/pooling-profile maxThreadsActive=50