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

做者简介

超哥，2008年毕业后进入IT行业，目前就任于饿了么物流架构部，曾就任于联想研究院的AR设备视觉团队和阿里巴巴的业务中台团队。 工做内容涉及大数据计算平台构建，计算视觉云端应用，业务中间件研发以及业务领域模型抽象与实现等。 即时配送业务的高速增加，对系统的复杂度提出了更大的挑战，同时也给咱们足够多的场景去尝试与征服。

开发同窗反馈应用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被坑了。

阅读博客还不过瘾？

欢迎你们扫二维码加入交流群，讨论和博客有关的技术问题，还能够和博主有更多互动

博客转载、线下活动及合做等问题请邮件至 shadowfly_zyl@hotmail.com 进行沟通