使用Docker容器时需要更改GC并发参数配置

标签: docker 容器 需要 | 发表时间:2015-10-08 20:18 | 作者:
出处:http://www.iteye.com
最近在做统一服务优化时发现使用容器时垃圾回收偏长,而我们的服务是一个响应时间优先的应用,需要对GC进行一些调优,在对容器内Java应用进行GC时发现:
 
(8核)如下是8核机器的GC,CMS,young gc基本在100ms左右
[GC (Allocation Failure) 1540815K->708720K(1992320K), 0.1204106 secs]
[GC (Allocation Failure) 1547632K->718037K(1992320K), 0.1039874 secs]
[GC (Allocation Failure) 1568245K->734990K(1992320K), 0.0979778 secs]
[GC (Allocation Failure) 1573902K->739338K(1992320K), 0.1270793 secs]
[GC (Allocation Failure) 1578250K->743388K(1992320K), 0.1074495 secs]
[GC (Allocation Failure) 1582300K->749564K(1992320K), 0.1199881 secs]
[GC (Allocation Failure) 1588476K->752993K(1992320K), 0.1134528 secs]
[GC (Allocation Failure) 1591905K->761514K(1992320K), 0.1208703 secs]
[GC (Allocation Failure) 1600426K->762095K(1992320K), 0.1214570 secs]
[GC (Allocation Failure) 1601007K->764275K(1992320K), 0.1035069 secs]
[GC (CMS Initial Mark) 775325K(1992320K), 0.0122687 secs]
[GC (CMS Final Remark) 1174093K(1992320K), 0.2219463 secs]
[GC (Allocation Failure) 1075577K->241414K(1992320K), 0.0959227 secs]
[GC (Allocation Failure) 1080326K->246942K(1992320K), 0.1073993 secs]
 
(8核)经发现与GC线程有关,通过指定并发GC线程数 -XX:ParallelGCThreads=8 -XX:ConcGCThreads=4,得到
[GC (Allocation Failure) 1631622K->798323K(1992320K), 0.0408915 secs]
[GC (Allocation Failure) 1637235K->797560K(1992320K), 0.0423643 secs]
[GC (Allocation Failure) 1636472K->803864K(1992320K), 0.0422181 secs]
[GC (Allocation Failure) 1642776K->813965K(1992320K), 0.0429882 secs]
[GC (Allocation Failure) 1686836K->850230K(1992320K), 0.0521587 secs]
[GC (Allocation Failure) 1689142K->858658K(1992320K), 0.0496138 secs]
[GC (Allocation Failure) 1697570K->858148K(1992320K), 0.0439780 secs]
[GC (Allocation Failure) 1697059K->865706K(1992320K), 0.0517013 secs]
[GC (CMS Initial Mark) 865828K(1992320K), 0.0184015 secs]
[GC (CMS Final Remark) 1198017K(1992320K), 0.1831652 secs]
[GC (Allocation Failure) 1132594K->301826K(1992320K), 0.0444428 secs]
[GC (Allocation Failure) 1140738K->305794K(1992320K), 0.0428419 secs]
[GC (Allocation Failure) 1144679K->312688K(1992320K), 0.0545760 secs]
[GC (Allocation Failure) 1151600K->320109K(1992320K), 0.0410423 secs]
[GC (Allocation Failure) 1159021K->320191K(1992320K), 0.0411587 secs]
[GC (Allocation Failure) 1159103K->330729K(1992320K), 0.0387938 secs]
[GC (Allocation Failure) 1169641K->331256K(1992320K), 0.0393934 secs]
[GC (Allocation Failure) 1170163K->343068K(1992320K), 0.0419092 secs]
 
(16核)而下边是-XX:ParallelGCThreads=16 -XX:ConcGCThreads=8
[GC (Allocation Failure) 1551548K->713703K(1992320K), 0.0400264 secs]
[GC (Allocation Failure) 1552615K->716536K(1992320K), 0.0463409 secs]
[GC (Allocation Failure) 1555448K->723921K(1992320K), 0.0313725 secs]
[GC (Allocation Failure) 1562833K->728720K(1992320K), 0.0333375 secs]
[GC (Allocation Failure) 1567629K->734094K(1992320K), 0.0352418 secs]
[GC (Allocation Failure) 1573006K->739880K(1992320K), 0.0368524 secs]
[GC (Allocation Failure) 1578792K->741607K(1992320K), 0.0418331 secs]
[GC (Allocation Failure) 1580519K->749161K(1992320K), 0.0379511 secs]
[GC (Allocation Failure) 1588073K->755358K(1992320K), 0.0347147 secs]
[GC (Allocation Failure) 1594270K->761399K(1992320K), 0.0379215 secs]
[GC (Allocation Failure) 1600311K->765948K(1992320K), 0.0348537 secs]
[GC (Allocation Failure) 1604858K->774675K(1992320K), 0.0371332 secs]
[GC (CMS Initial Mark) 774724K(1992320K), 0.0120999 secs]
[GC (CMS Final Remark) 1067302K(1992320K), 0.1657415 secs]
[GC (Allocation Failure) 1130442K->286546K(1992320K), 0.0299338 secs]
[GC (Allocation Failure) 1125458K->298132K(1992320K), 0.0328611 secs]
[GC (Allocation Failure) 1137044K->304370K(1992320K), 0.0357785 secs]
 
(8核)而如果换成UseParallelGC,young gc不错,而full gc偏慢,线上如果没有配置CMS的话,默认是用这个
[GC (Allocation Failure) 1993894K->1000058K(2072576K), 0.0396914 secs]
[GC (Allocation Failure) 1999482K->1007021K(2072576K), 0.0403703 secs]
[GC (Allocation Failure) 2006445K->1011597K(2068480K), 0.0432666 secs]
[GC (Allocation Failure) 2006925K->1016275K(2070528K), 0.0450037 secs]
[GC (Allocation Failure) 2011603K->1020929K(2070528K), 0.0490808 secs]
[GC (Allocation Failure) 2016257K->1025389K(2070528K), 0.0395652 secs]
[GC (Allocation Failure) 2020717K->1029915K(2070528K), 0.0415800 secs]
[GC (Allocation Failure) 2025243K->1035623K(2070528K), 0.0534249 secs]
[GC (Allocation Failure) 2030951K->1041520K(2072576K), 0.0473277 secs]
[GC (Allocation Failure) 2040944K->1046783K(2072576K), 0.0447377 secs]
[GC (Allocation Failure) 2046207K->1052829K(2068480K), 0.0466185 secs]
[GC (Allocation Failure) 2048157K->1057749K(2070528K), 0.0435571 secs]
[GC (Allocation Failure) 2053077K->1063253K(2070528K), 0.0434343 secs]
[GC (Allocation Failure) 2058581K->1067759K(2070528K), 0.0402552 secs]
[Full GC (Ergonomics) 1067759K->235608K(2070528K), 0.4808497 secs]
[GC (Allocation Failure) 1230936K->247560K(2070528K), 0.0318850 secs]
[GC (Allocation Failure) 1242888K->254827K(2070528K), 0.0340009 secs]
[GC (Allocation Failure) 1250155K->259247K(2066432K), 0.0337921 secs]
[GC (Allocation Failure) 1250479K->264965K(2068480K), 0.0585058 secs]
 
虽然GC不如物理机,但是可以满足我们的需要了。
注:

 

1、因为容器不是物理隔离的,比如使用Runtime.getRuntime().availableProcessors() ,会拿到物理CPU个数,而不是容器申请时的个数,
2、CMS在算GC线程时默认是根据物理CPU算的:( http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-November/008952.html
年轻代的并行线程数(ParallelGCThreads):
return (ncpus <= 8) ? ncpus : MAX2(8, ncpus / 2)
CMS并行线程数(ConcGCThreads):
 if (AdjustGCThreadsToCores) {
   FLAG_SET_DEFAULT(ConcGCThreads, ParallelGCThreads / 2);
 } else {
   FLAG_SET_DEFAULT(ConcGCThreads, (3 + ParallelGCThreads) / 4);
 }
因为我们升级到了JDK8/Tomcat8, 遇到以下问题:
1、Tomcat8使用Nio2时有时候会遇到如下警告,暂时没有升级上去
org.apache.tomcat.util.net.AbstractEndpoint countDownConnection
WARNING: Incorrect connection count, multiple socket.close called on the same socket.
 
2、使用G1垃圾回收时,在我们的小堆上没有多大优势,暂时没有使用。
 
我们线上某服务的JVM参数
export JAVA_OPTS="-Djava.library.path=/usr/local/lib -server -XX:ReservedCodeCacheSize=64m -XX:TLABWasteTargetPercent=10 -XX:-UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UnlockDiagnosticVMOptions -XX:ParallelGCThreads=8 -XX:ConcGCThreads=4 -Xss256k -server -Xms2g -Xmx2g -XX:MaxDirectMemorySize=256m -XX:MaxTenuringThreshold=3 -XX:NewRatio=1 -XX:SurvivorRatio=8 -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=32768 -XX:+AlwaysPreTouch
 


已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [docker 容器 需要] 推荐:

使用Docker容器时需要更改GC并发参数配置

- - ITeye博客
最近在做统一服务优化时发现使用容器时垃圾回收偏长,而我们的服务是一个响应时间优先的应用,需要对GC进行一些调优,在对容器内Java应用进行GC时发现:. (8核)如下是8核机器的GC,CMS,young gc基本在100ms左右. (8核)经发现与GC线程有关,通过指定并发GC线程数 -XX:ParallelGCThreads=8 -XX:ConcGCThreads=4,得到.

关于docker容器的监控

- - CSDN博客推荐文章
1 docker inspect [容器ID | 镜像ID]. 查看容器创建时间、容器的IP、映射的端口、挂载的目录等信息. 此命令同样也能用来查看镜像的详细信息. 2 docker stats 容器ID. 用来查看容器的资源使用情况,如:CPU、内存、网络、I/O. 另外,在docker的配置文件中添加如下的参数之后,可以采用curl来调用stats API接口.

Docker容器安全性分析

- - FreeBuf互联网安全新媒体平台
Docker是目前最具代表性的容器技术之一,对云计算及虚拟化技术产生了颠覆性的影响. 本文对Docker容器在应用中可能面临的安全问题和风险进行了研究,并将Docker容器应用环境中的安全机制与相关解决方案分为容器虚拟化安全、容器安全管理、容器网络安全三部分进行分析. 一、从虚拟化安全到容器安全 .

调试 Docker 容器内部进程

- - 掘金后端
摘要:本文以 Nebula Graph 进程为例,讲解如何不破坏原有容器的内容,也不用在其中安装任何的工具包前提下,像在本地一样来调试进程. 在开发或者测试过程中,我们经常会用到. vesoft-inc/nebula-docker-compose 这个 repo 下的部署方式,因为当初为了尽可能的压缩每个.

减少使用Java应用服务器,迎接Docker容器

- - ITeye资讯频道
【编者的话】随着Docker的发展,越来越多的应用开发者开始使用Docker. James Strachan写了一篇有关Java开发者如何使用Docker进行轻量级快速开发的文章. 他告诉我们,使用Docker和服务发现的机制,可以有效减轻Java运维人员的负担,进行项目的快速启动和持续迭代. 多年来,Java生态系统一直在使用应用服务器.

理解Docker跨多主机容器网络

- - Tony Bai
在 Docker 1.9 出世前,跨多主机的容器通信方案大致有如下三种:. 将宿主机A的端口P映射到容器C的网络空间监听的端口P’上,仅提供四层及以上应用和服务使用. 这样其他主机上的容器通过访问宿主机A的端口P实 现与容器C的通信. 显然这个方案的应用场景很有局限. 2、将物理网卡桥接到虚拟网桥,使得容器与宿主机配置在同一网段下.

Docker容器的自动化监控实现

- - DockerInfo
2016年对于网易杭州研究院(以下简称“杭研”)而言是重要的,成立十周年之际,杭研正式推出了网易云. “十年•杭研技术秀”系列文章,由杭研研发团队倾情奉献,为您展示杭研那些有用、有趣的技术实践经验,涵盖云计算、大前端、信息安全、运维、QA、大数据、人工智能等领域,涉及前沿的分布式、 容器、深度学习等技术.

docker容器部署Spring Boot项目及更新

- - 编程语言 - ITeye博客
Docker这项容器技术已经是十分的火热了,读者要是不了解docker的话可以吧docker先理解为虚拟机. 我们的Springboot最终是要部署在Linux上的,docker作为Linux轻量级的实现. docker也是可以用来部署Springboot应用的. 1.创建Dockerfile . 创建一个文件名为Dockerfile的文件,复制以下内容到文件中.

elk-filebeat收集docker容器日志 - devzxd - 博客园

- -
filebeat安装与配置. 1、使用docker-compose文件构建elk. 2、执行docker-compose up -d 启动elk. 可以使用docker logs 命令查看elk启动日志. 启动成功后打开浏览器访问 http://127.0.0.1:5601. 关于filebeat本文也不做过多介绍.

浅析 Docker 容器安全管控方法

- - IT瘾-dev
二、浅析Docker容器生命周期安全问题. 2.3 容器系统入侵检测与防护. 2.4 容器网络入侵检测与防护. 2.6 Docker及其配套软件漏洞. 三、浅谈Docker容器安全现状改善方法. 3.1 “镜像深度扫描”管控方法. 3.2 “容器系统入侵检测与防护”管控方法. 3.3 “容器网络入侵检测与防护”管控方法.