背景起因:
记起以前的另一次也是关于内存的调优分享下
有个系统平时运行非常稳定运行(没经历过大并发考验),然而在一次活动后,人数并发一上来后,系统开始卡。
我按经验开始调优,在每个关键步骤的加入如下代码耗时统计进行压测:
long startTime = System.currentTimeMillis();
callRpc(); //这里比如调用RPC伪代码,当然还在插入数据库,中间件地方都加入统计
long costTime = (System.currentTimeMillis() - startTime);
//统计600毫秒以上耗时
if (costTime > 600) {
logger.warning("callRpc cost time:" + costTime);
}
然后去grep日志, 最后神奇的发现各个地方都有超过600毫秒的地方...
然后各种定位的误导...
当然最终是解决了,原因是由于程序里使用了大对象导致
细分析,即使这种情况深研究也是分很多情况的
问题重现:
原因分析:
由于系统中使用了大对象,当并发来临,内存讲被吃紧,将有可能引起如下三种情况
第一种情况,系统内存够用(JVM内存未使用到SWAP内存),但JVM内存不够,最终导致JVM的频繁垃圾回收(FGC),严重影响性能 (stop the word)
第二种情况,系统内存不够,把JVM堆部分用到了SWAP,那么此时的垃圾回收需要把SWAP的内存换回到系统物理内存再进行JVM的垃圾回收。最大影响,导致每次GC的时间变得很久
<

本文通过一个实例分析了由于大对象使用导致的Java内存不足问题,进而引发了频繁的Full GC和使用SWAP空间带来的性能下降。在并发增加时,三种不同内存状况(内存够用、JVM使用SWAP、物理内存不足)对系统性能的影响各有特点。结论强调了避免JVM使用SWAP的重要性,并提示频繁FGC可能误导性能瓶颈定位。
最低0.47元/天 解锁文章
1144

被折叠的 条评论
为什么被折叠?



