Java应用Docker化部署GC变长的踩坑经历

阿里云幸运券

开发同学反馈应用docker化部署之后,gc时间比KVM部署时涨了好几倍,最近正好手热,上机器撸了一把。
问题定位
通过gc日志收集工具,查看jvm的gc信息,平均单次ygc的时间非常不稳定,但基本上都在100ms以上。

从集群里随机挑了几台机器看了一下gc log,每次gc的堆大小都比较正常,但是时间不太科学。

猜测是gc线程出了问题。jinfo查看了

服务的docker容器分配了8核16g的资源,上面拉出来的gc线程和并发标记线程数是38和10,显然不科学(猜测拉的宿主机的核数)。
默认的gc线程和并发标记线程数计算公式如下:

通过与运维同学沟通,了解到宿主机是56核,根据上面公式进行计算,对上了。
修改配置灰度验证
从集群中随机挑选几台机器进行灰度,修改下jvm启动参数,增加 -XX:ParallelGCThreads=8(8是容器核数),设置了ParallelGCThreads之后CMS的并发标记线程数会同步下降。

运行了一个晚上和一个白天,发现灰度机的ygc变的非常平稳,时间降到了 10ms左右,gc的log如下:

结论
因为容器不是物理隔离的,部署的java应用,务必要指定-XX:ParallelGCThreads=CPU_COUNT ,以防被YGC被坑了。

腾讯云代金券

原文链接

https://juejin.im/post/5b63ff20e51d4519946020b1

服务推荐

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值