故障重现(内存篇2),JAVA内存不足导致频繁回收和swap引起的性能问题

背景起因:

记起以前的另一次也是关于内存的调优分享下

有个系统平时运行非常稳定运行(没经历过大并发考验),然而在一次活动后,人数并发一上来后,系统开始卡。

我按经验开始调优,在每个关键步骤的加入如下代码耗时统计进行压测:

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)

第二种情况,系统内存不够,把J

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值