对于GC回收优化转贴文章的一点补充

    记得在我前一阵子的blog中写了关于jdk1.5的pool的内存溢出问题，这次乘着新的memcache客户端的使用，做了一次全面的压力测试。

<?xml:namespace prefix = o ?>jdk采用1.5的压力测试结果压了一个周末回来就无法响应了，看了看它的GC输出：

全都是[Full GC [Tenured: 786431K->786431K(786432K), 3.4802480 secs] 1022399K->1022399K(1022400K), [Perm : 36711K->36711K(98304K)], 3.4808510 secs]

 

替换jdk1.5为jdk1.6昨天中午开始做压力测试到今天中午我取了一下日志，看见GC输出如下：

[GC [PSYoungGen: 256608K->3608K(257792K)] 859002K->606698K(1044224K), 0.0562040 secs] [Times: user=0.17 sys=0.01, real=0.05 secs]

 

这就很明显的看出了差别了，前者已经把家底全部都用完了，出于out of memory的状态了。后者还是普通的GC回收，回收效果很好，同时看了看jboss启动的时候回收后占用的YoungGen就1300K左右，因此跑了一天的压力测试应该说还算是正常。

 

Full GC也就是在年轻代无法满足内存分配要求的时候才去做，这时候其实对于中老两代来说应该已经可能被占用完毕了，Full GC发生频率也越来越高，服务器响应速度也越来越慢。

因此对于持久的压力测试来说，打印出GC可以很好的分析出应用本身的内存使用状况，避免长期运行中少量内存泄露最终导致的应用不可用。

 

顺便说一下memcache 客户端修改后的测试结果：

  测试方案：

                   开始50个并发，每个并发每次请求完毕后休息0.1秒，10分钟后增长50个并发，按此规律增长到500并发。

                   新旧版本SIP是在JDK1.5环境下完成的压力测试，

                   压力机和以前一样，是10.2.226.40，DELL1950，8CPU，8G内存。

                   压力机模拟发出对一个需要签名的API不断的调用请求。

 

         测试结论：

                   老版本的SIP性能和以前一样，并发500的时候，TPS接近480，CPU 68%

                   新版本的SIP性能比老版本好很多，并发500的时候，TPS接近770，且系统压力很小，CPU利用率平均只有16%