Notice: Constant WP_DEBUG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 12

Notice: Constant WP_DEBUG_LOG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 13

Notice: Constant WP_DEBUG_DISPLAY already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 14
聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些【zoues.com】 – zoues

LOADING

Follow me

聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些【zoues.com】
四月 17, 2017|DockerPaaS

聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些【zoues.com】

聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些【zoues.com】

聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些

作者:Rafael Benevides

翻译:李强

来源:DockOne.io

原文链接:http://www.dockone.io/article/2249


很多开发者会(或者应该)知道,当我们为运行在Linux容器(docker, rkt, runC, lxcfs, etc,)中的Java程序去设置JVM的GC、堆大小和运行时编译器的参数时并没有得到预想的效果。当我们通过“java -jar mypplication-fat.jar”的方式而不设置任何参数来运行一个Java应用时,JVM会根据自身的许多参数进行调整,以便在执行环境中获得最优的性能。


本篇博客将通过简单的方式向开发人员展示在将Java应用运行在Linux容器内时需要了解的内容。

我们倾向于认为容器可以像虚拟机一样可以完整的定义虚拟机的CPU个数和虚拟机的内存。容器更像是一个进程级别的资源(CPU、内存、文件系统、网络等)隔离。这种隔离是依赖于Linux内核中提供的一个cgroups的功能。

然而,一些可以从运行时环境中收集信息的应用程序在cgroups功能出现之前已经存在。在容器中执行命令 ‘top‘, ‘free‘, ‘ps’,也包括没有经过优化的JVM是一个会受到高限制的Linux进程。让我们来验证一下。



问题


为了展示遇到的问题,我使用命令“docker-machine create -d virtualbox –virtualbox-memory ‘1024’ docker1024”在虚拟机中创建了一个具有1GB内存的Docker守护进程,接下来在3个Linux容器中执行命令“free -h”,使其只有100MB的内存和Swap。结果显示所有的容器总内存是995MB。

聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些


即使是在 Kubernetes/OpenShift集群中,结果也是类似的。我在一个内存是15G的集群中也执行了命令使得Kubernetes Pod有511MB的内存限制(命令:“kubectl run mycentos –image=centos -it –limits=’memory=512Mi’”),总内存显示为14GB。

聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些


想要知道为什么是这样的结果,可以去阅读此篇博客文章 “Memory inside Linux containers – Or why don’t free and top work in a Linux container?”(https://fabiokung.com/2014/03/13/memory-inside-linux-containers/)

我们需要知道Docker参数 (-m, –memory和–memory-swap)和Kubernetes参数 (–limits)会让Linux内核在一个进程的内存超出限制时将其Kill掉,但是JVM根本不清楚这个限制的存在,当超过这个限制时,不好的事情发生了!

为了模拟当一个进程超出内存限制时会被杀死的场景,我们可以通过命令“docker run -it –name mywildfly -m=50m jboss/wildfly”在一个容器中运行WildFly Application Server并且为其限制内存大小为50MB。在这个容器运行期间,我们可以执行命令“docker stats”来查看容器的限制。

聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些


但是过了几秒之后,容器Wildfly将会被中断并且输出信息:*** JBossAS process (55) received KILL signal ***

通过命令 “docker inspect mywildfly -f ‘{{json .State}}’”可以查看容器被杀死的原因是发生了OOM(内存不足)。容器中的“state”被记录为OOMKilled=true 。

聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些



这将怎样影响Java应用


在Docker宿主机中创建一个具有1GB内存的虚拟机(在之前使用命令已经创建完毕 “docker-machine create -d virtualbox –virtualbox-memory ‘1024’ docker1024”) ,并且限制一个容器的内存为150M,看起来已经足够运行这个在 Dockerfile中设置过参数-XX: PrintFlagsFinal 和 -XX: PrintGCDetails的Spring Boot application了。这些参数使得我们可以读取JVM的初始化参数并且获得 Garbage Collection (GC)的运行详细情况。


尝试一下:

$ docker run -it –rm –name mycontainer150 -p 8080:8080 -m 150M rafabene/java-container:openjdk


我也提供了一个访问接口“/api/memory/”来使用String对象加载JVM内存,模拟大量的消耗内存,可以调用试试:

$ curl http://X41X:8080/api/memory


这个接口将会返回下面的信息 “Allocated more than 80% (219.8 MiB) of the max allowed JVM memory size (241.7 MiB)


在这里我们至少有2个问题:

  • 为什么JVM会允许241.7MiB的最大内容?

  • 如果容器已经限制了内存为150MB,为什么允许Java分配内存到220MB?


首先,我们应该重新了解在JVM ergonomic page中所描述的 “maximum heap size”的定义,它将会使用1/4的物理内存。JVM并不知道它运行在一个容器中,所以它将被允许使用260MB的最大堆大小。通过添加容器初始化时的参数-XX: PrintFlagsFinal,我们可以检查这个参数的值。

$ docker logs mycontainer150|grep -i MaxHeapSize
uintx MaxHeapSize := 262144000 {product}


其次,我们应该理解当在docker命令行中设置了 “-m 150M”参数时,Docker守护进程会限制RAM为150M并且Swap为150M。从结果上看,一个进程可以分配300M的内存,解释了为什么我们的进程没有收到任何从Kernel中发出的退出信号。

更多的关于Docker命令中内存限制 (–memory)和Swap (–memory-swap)的差别可以参考这里(https://docs.docker.com/engine/reference/run/#user-memory-constraints)。


更多的内存是解决方案吗?


开发者如果不理解问题可能会认为运行环境中没有为JVM提供足够的内存。通常的解决对策就是为运行环境提供更多的内存,但是实际上,这是一个错误的认识。

假如我们将Docker Machine的内存从1GB提高到8GB(使用命令 “docker-machine create -d virtualbox –virtualbox-memory ‘8192’ docker8192”),并且创建的容器从150M到800M:

$ docker run -it –name mycontainer -p 8080:8080 -m 800M rafabene/java-container:openjdk


此时使用命令 “curl http://X58X:8080/api/memory” 还不能返回结果,因为在一个拥有8GB内存的JVM环境中经过计算的MaxHeapSize大小是2092957696(~ 2GB)。可以使用命令“docker logs mycontainer|grep -i MaxHeapSize”查看。

聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些


应用将会尝试分配超过1.6GB的内存,当超过了容器的限制(800MB的RAM 800MB的Swap),进程将会被kill掉。 

很明显当在容器中运行程序时,通过增加内存和设置JVM的参数不是一个好的方式。当在一个容器中运行Java应用时,我们应该基于应用的需要和容器的限制来设置最大堆大小(参数:-Xmx)。


解决方案是什么?


在Dockerfile中稍作修改,为JVM指定扩展的环境变量。修改内容如下:

CMD java -XX: PrintFlagsFinal -XX: PrintGCDetails $JAVA_OPTIONS -jar java-container.jar


现在我们可以使用JAVA_OPTIONS的环境变量来设置JVM Heap的大小。300MB看起来对应用足够了。稍后你可以查看日志,看到Heap的值是 314572800 bytes ( 300MBi)。

Docker下,可以使用“-e”的参数来设置环境变量进行切换。

$ docker run -d –name mycontainer8g -p 8080:8080 -m 800M -e JAVA_OPTIONS=’-Xmx300m’ rafabene/java-container:openjdk-env

$ docker logs mycontainer8g|grep -i MaxHeapSize
uintx MaxHeapSize := 314572800 {product}


在Kubernetes中,可以使用“–env=[key=value]”来设置环境变量进行切换:

$ kubectl run mycontainer –image=rafabene/java-container:openjdk-env –limits=’memory=800Mi’ –env=”JAVA_OPTIONS=’-Xmx300m'”

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mycontainer-2141389741-b1u0o 1/1 Running 0 6s

$ kubectl logs mycontainer-2141389741-b1u0o|grep MaxHeapSize
uintx MaxHeapSize := 314572800 {product}



还能再改进吗?


有什么办法可以根据容器的限制来自动计算Heap的值?


事实上如果你的基础Docker镜像使用的是由Fabric8提供的,那么就可以实现。镜像fabric8/java-jboss-openjdk8-jdk使用了脚本来计算容器的内存限制,并且使用50%的内存作为上限。也就是有50%的内存可以写入。你也可以使用这个镜像来开/关调试、诊断或者其他更多的事情。让我们看一下一个Spring Boot应用的 Dockerfile : 

FROM fabric8/java-jboss-openjdk8-jdk:1.2.3
ENV JAVA_APP_JAR java-container.jar
ENV AB_OFF true
EXPOSE 8080
ADD target/$JAVA_APP_JAR /deployments/


就这样!现在,不管容器的内存限制如何,我们的Java应用将在容器中自动的调节Heap大小,而不是再根据宿主机来设置。

聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些
聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些
聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些


总结到目前为止,Java JVM还不能意识到其是运行在一个容器中 — 某些资源在内存和CPU的使用上会受到限制。因此,你不能让JVM自己来设置其认为的最优的最大Heap值。

一个解决对策是使用Fabric8作为基础镜像,它可以意识到应用程序运行在一个受限制的容器中,并且在你没有做任何事情的情况下,可以自动的调整最大Heap的值。

在JDK9中已经开始进行尝试在容器 (i.e. Docker)环境中为JVM提供cgroup功能的内存限制。相关信息可以查看:http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49


聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些

上期回顾

私有云 | 混合云 | 自动化运维

关于BoCloud博云

BoCloud 博云,为企业级客户提供针对互联网化、大数据业务应用、去IOE 化(X86 服务器规模化应用)的底层云化架构和智能云运维系统,运用最新容器技术协助企业完成IT 系统云架构的实施和运维, 帮助企业客户降低成本、提升效率、简化运维、提高系统可靠性和安全性。凭借对客户业务流程和应用的深刻理解,以及先进技术产品的持续研发, BoCloud 博云以创新云技术支撑企业核心业务,促进企业IT 系统的不断进化。

www.bocloud.com.cn

聊聊代码 | 在Docker中运行Java:为了防止失败,你需要知道这些
no comments
Share