目前性能测试组正在对独立秒杀进行性能压测,性能抖动特别厉害。

 

由于独立秒杀的接口大多数是经过volicity渲染过的页面和数据的整合,所以在压测的时候有很多volicity的错误。初步判定,感觉是volicity的性能问题才导致的。但是通过排查volicity发现,此版本没有网传的性能问题,而且代码层面上也没见到有过多的性能问题点。

之后通过查看jvm的堆内内存才发现,老年代的内存无法释放,总是会经过很长一段时间,大概三十四分钟后才会释放。感觉很奇怪:

image

从上图可以看到,堆内内存涨上去后,基本上就下不来了, 这些没释放的内存,基本上都在老年代。初步判定为jvm堆内内存要么有大对象,要么什么东西一直持有,并未释放。

之后从服务器上dump数据下来,然后通过mat加载后,得到的分析如下:

image

可以看到,系统中,有一个ConcurrentHashMap的容器里面,貌似对每个http请求,都做了一次缓存。考虑到目前做的是压测,那么也就是说瞬间涌入千万级别的请求也不为过,ConcurrentHashMap的体积在很短的时间就会暴涨,势必会带来频繁的gc问题。如果只是保存http请求状态,为什么http请求完毕,不会释放呢?

带着疑问去应用里面进行排查,发现应用里面根本没有直接使用ConcurrentHashmap对象。那么也就是说ConcurrentHashmap对象也许是存在什么jar包里面了。经过排查jar包,也没发现什么地方使用concurrenthashmap,顿时陷入了死局。

后来,压测组发来一篇文章:压力测试中JVM内存暴涨原因分析实战, 看完文章,和我的遭遇非常一致,联想到目前压测直接使用ip+端口压测,直接打到tomcat上进行压测,而且接口返回数据都是经过velocity渲染的模板和数据组合,是有前端页面的。所以说,按照文章中的说法,应该是tomcat对每一个进来的请求都会将状态会话保持放到ConcurrentHashmap中导致的,而且这个状态会话保持默认30分钟后过期,这也是为啥GC一直下不来的原因了。

为了印证此说法,按照此文的建议, Memory Fully utilized by Java ConcurrentHashMap (under Tomcat),在web.xml中设置session过期时间为1分钟:

<session-config>
    <session-timeout>1</session-timeout>
</session-config>

之后修改代码,上预发,然后让压力机单压预发这台机器,可以看到堆内存回收如下:

image

可以看到当堆内存打到极高点后,jvm很快进行了一次回收,而且此次回收比较彻底。

验证完毕,看来是这个原因。希望对你有帮助。

posted on 2018-10-18 13:15  程序诗人  阅读(3715)  评论(2编辑  收藏  举报