【JVM调优】:解决生产环境系统卡死

文章描述了一个金融类私募基金直销平台在上线后遇到的系统卡顿问题。通过分析GC日志,发现频繁的YGC和FGC是问题所在。经过排查,确认了内存配置不当和任务执行频率过高是主要原因。通过调整内存配置,关闭UseAdaptiveSizePolicy选项,以及降低任务执行频率,成功解决了系统卡顿问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

项目场景:

金融类项目,私募基金直销平台,用户量很少


问题描述

项目上线后系统越来越卡,由于单机部署,运维同学怀疑是资源问题(先反馈给了运维),加了内存和带宽,问题依然没有解决。


原因分析:

生产环境,涉及隐私截图没上!

1、初步试探

jps -l 查看服务pid,找到对应服务。
jstat -gc pid 1000 20 打印GC情况,间隔1S共20次。

20S之内执行了28次YGC和2次FGC,GC时间1S多!
服务重启短短几天FGC执行了六万多次,GC累计时长已达将近6万秒!(特意对比了一下其他项目,加一起都没这么多……)

这个数据着实恐怖,来看一下正常GC的经验值:
YGC 执行时间不超过50ms,执行频率不小于10s每次
FGC 执行时间不超过1s,执行频率不低于10分钟每次

很明显,GC执行频率已经远远超过正常值,顺着这个结果分析,猜测原因大概有两个:
1,内存泄露:代码有严重的问题;
2,内存不够:单机部署,确实扛不住客户量。

review了下提交记录,近期并没有修改代码。内存泄露的对象一般会长期持有回收不掉,随着积累大概率出现内存溢出的情况。但是,这里没有出现内存溢出,只是频繁GC,难道真是内存不够用了?
于是先排除第一种可能,加了内存,重启服务……

2、循循渐进

重启完服务,问题并没有解决,GC频率很快上来了,于是继续分析……

eden区YGC后有100多M的对象直接进入到了old区!
s区扩容,抢占eden内存,但是不足以承载eden区GC后的存活对象,所以有100多M的对象直接进入到了old区。

jmap -heap pid 查看堆信息

eden:s != 8:1 ,s区3.5M,怎么这么小?

jinfo pid 查看JVM配置信息

发现了这个配置:-XX:+UseParallelGC,没错,Java8的默认垃圾回收器paralleGC。而paralleGC有个默认开启的配置:UseAdaptiveSizePolicy,该配置默认开启堆内存new区的自动分配,于是SurvivorRatio就失效了。YGC频率加,eden区会扩容增加占比,s区占比就会被缩减,eden区回收后的存活对象s区放不下就会更快的往old转移,old区对象激增导致FGC频率加快……

于是在启动脚本里添加了-XX:-UseAdaptiveSizePolicy,把动态分配区内存给关了。

3、拨开云雾

等待了一天,看下GC情况:
FGC频率回到了一个正常的值,同时也基本可以确定,s区太小,会导致FGC频率增大。

但是,20S内64次YGC,虽然GC时间短,客户卡顿的感知没那么明显,但这个值还是太高了。

然后再把时间间隔调成100ms,看下情况:
FGC频率回到了一个正常的值,同时也基本可以确定,s区太小,会导致FGC频率增大。

但是,20S内64次YGC,虽然GC时间短,客户卡顿的感知没那么明显,但这个值还是太高了。

然后再把时间间隔调成100ms,看下情况:

FGC频率回到了一个正常的值,同时也基本可以确定,s区太小,会导致FGC频率增大。

但是,20S内64次YGC,虽然GC时间短,客户卡顿的感知没那么明显,但这个值还是太高了。

然后再把时间间隔调成100ms,看下情况:

eden区增的很快,s区空间始终没有空闲出来,FGC频率也上来了。(上午看得时候才12次FGC)
回看下new区的大小:eden区256M,s区42.5M,eden区增的很快,s区的内存始终没清掉,s区是不是太小了?
再回看下堆内存配置:xms: 1G xmx: 3G,初始内存是不是给少了,而且客户只有一台服务器,把初始内存也设成3G?

-Xms3096m 更改初始内存

重启服务,再看下GC情况:

YGC频率降低到20S以上,FGC也正常,然后就又等了一天继续观察GC情况:

FGC增了一次,YGC频率很高。

然后看了下日志,恰巧此时没有人使用,所以就很好奇,哪来这么多对象?
开始怀疑系统是不是有不正常的定时任务,于是查看代码,发现任务都没有打日志!!!我的一口老血啊……最后登录XXLJOB后台,发现任务配置被改了,有很几个任务改成了一两分钟,甚至还有一秒执行一次的(数据同步的任务,数据量还不小。)!!!


解决方案:

问题解决:
1,降低任务的执行频率,因为系统本身用户量不大,签约系统对数据实时性要求不高。
2,和客户沟通下,如果业务对数据实时性要求确实这么高,那么适当放大new区比例,因为数据同步大都是临时对象。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

砍光二叉树

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值