技术进阶：Docker容器中的JVM资源该如何被安全的限制？

GluttonousZX

2019-02-12

关注关注

作者：青木

原文：https://qingmu.io/2018/12/17/How-to-securely-limit-JVM-resources-in-a-container/

前言

Java与Docker的结合，虽然更好的解决了application的封装问题。但也存在着不兼容，比如Java并不能自动的发现Docker设置的内存限制，CPU限制。

这将导致JVM不能稳定服务业务！容器会杀死你JVM进程，而健康检查又将拉起你的JVM进程，进而导致你监控你的Pod一天重启次数甚至能达到几百次。

我们希望当Java进程运行在容器中时，Java能够自动识别到容器限制，获取到正确的内存和CPU信息，而不用每次都需要在kubernetes的yaml描述文件中显示的配置完容器，还需要配置JVM参数。

使用JVM MaxRAM参数或者解锁实验特性的JVM参数，升级JDK到10+，我们可以解决这个问题（也许吧~.~）。

首先Docker容器本质是是宿主机上的一个进程，它与宿主机共享一个/proc目录，也就是说我们在容器内看到的/proc/meminfo，/proc/cpuinfo与直接在宿主机上看到的一致，如下。

Host：

cat /proc/meminfo 
MemTotal: 197869260 kB
MemFree: 3698100 kB
MemAvailable: 62230260 kB

容器：

docker run -it --rm alpine cat /proc/meminfo
MemTotal: 197869260 kB
MemFree: 3677800 kB
MemAvailable: 62210088 kB

那么Java是如何获取到Host的内存信息的呢？没错就是通过/proc/meminfo来获取到的。

默认情况下，JVM的Max Heap Size是系统内存的1/4，假如我们系统是8G，那么JVM将的默认Heap≈2G。

Docker通过CGroups完成的是对内存的限制，而/proc目录是已只读形式挂载到容器中的，由于默认情况下Java压根就看不见CGroups的限制的内存大小，而默认使用/proc/meminfo中的信息作为内存信息进行启动，

这种不兼容情况会导致，如果容器分配的内存小于JVM的内存，JVM进程会被理解杀死。

内存限制不兼容

我们首先来看一组测试，这里我们采用一台内存为188G的物理机。

#free -g
 total used free shared buff/cache available
Mem: 188 122 1 0 64 64

以下的测试中，我们将包含OpenJDK的hotspot虚拟机，IBM的OpenJ9虚拟机。

以下测试中，我们把正确识别到限制的JDK，称之为安全（即不会超出容器限制不会被kill），反之称之为危险。

测试用例1（OpenJDK）

这一组测试我们使用最新的OpenJDK8-12，给容器限制内存为4G，看JDK默认参数下的最大堆为多少？看看我们默认参数下多少版本的JDK是安全的

命令如下，如果你也想试试看，可以用一下命令。

docker run -m 4GB --rm openjdk:8-jre-slim java -XshowSettings:vm -version
docker run -m 4GB --rm openjdk:9-jre-slim java -XshowSettings:vm -version
docker run -m 4GB --rm openjdk:10-jre-slim java -XshowSettings:vm -version
docker run -m 4GB --rm openjdk:11-jre-slim java -XshowSettings:vm -version
docker run -m 4GB --rm openjdk:12 java -XshowSettings:vm -version

OpenJDK8（并没有识别容器限制，26.67G）危险。

[root@xiaoke-test ~]# docker run -m 4GB --rm openjdk:8-jre-slim java -XshowSettings:vm -version
VM settings:
Max. Heap Size (Estimated): 26.67G
Ergonomics Machine Class: server
Using VM: OpenJDK 64-Bit Server VM
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

OpenJDK8 -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap （正确的识别容器限制，910.50M）安全。

[root@xiaoke-test ~]# docker run -m 4GB --rm openjdk:8-jre-slim java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XshowSettings:vm -version
VM settings:
Max. Heap Size (Estimated): 910.50M
Ergonomics Machine Class: server
Using VM: OpenJDK 64-Bit Server VM
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

OpenJDK 9（并没有识别容器限制，26.67G）危险。

[root@xiaoke-test ~]# docker run -m 4GB --rm openjdk:9-jre-slim java -XshowSettings:vm -version
VM settings:
Max. Heap Size (Estimated): 29.97G
Using VM: OpenJDK 64-Bit Server VM
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode)

OpenJDK 9 -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap（正确的识别容器限制，1G）安全。

[root@xiaoke-test ~]# docker run -m 4GB --rm openjdk:9-jre-slim java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XshowSettings:vm -version
VM settings:
Max. Heap Size (Estimated): 1.00G
Using VM: OpenJDK 64-Bit Server VM
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode)

OpenJDK 10（正确的识别容器限制，1G）安全。

[root@xiaoke-test ~]# docker run -m 32GB --rm openjdk:10-jre-slim java -XshowSettings:vm -XX:MaxRAMFraction=1 -version
VM settings:
Max. Heap Size (Estimated): 1.00G
Using VM: OpenJDK 64-Bit Server VM
openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Debian-2)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Debian-2, mixed mode)

OpenJDK 11（正确的识别容器限制，1G）安全。

[root@xiaoke-test ~]# docker run -m 4GB --rm openjdk:11-jre-slim java -XshowSettings:vm -version
VM settings:
Max. Heap Size (Estimated): 1.00G
Using VM: OpenJDK 64-Bit Server VM
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment (build 11.0.1+13-Debian-3)
OpenJDK 64-Bit Server VM (build 11.0.1+13-Debian-3, mixed mode, sharing)

OpenJDK 12（正确的识别容器限制，1G）安全。

[root@xiaoke-test ~]# docker run -m 4GB --rm openjdk:12 java -XshowSettings:vm -version
VM settings:
Max. Heap Size (Estimated): 1.00G
Using VM: OpenJDK 64-Bit Server VM
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment (build 12-ea+23)
OpenJDK 64-Bit Server VM (build 12-ea+23, mixed mode, sharing)

测试用例2（IBM OpenJ9）

docker run -m 4GB --rm adoptopenjdk/openjdk8-openj9:alpine-slim java -XshowSettings:vm -version
docker run -m 4GB --rm adoptopenjdk/openjdk9-openj9:alpine-slim java -XshowSettings:vm -version
docker run -m 4GB --rm adoptopenjdk/openjdk10-openj9:alpine-slim java -XshowSettings:vm -version
docker run -m 4GB --rm adoptopenjdk/openjdk11-openj9:alpine-slim java -XshowSettings:vm -version

OpenJDK8-OpenJ9（正确的识别容器限制，3G）安全。

[root@xiaoke-test ~]# docker run -m 4GB --rm adoptopenjdk/openjdk8-openj9:alpine-slim java -XshowSettings:vm -version
VM settings:
Max. Heap Size (Estimated): 3.00G
Ergonomics Machine Class: server
Using VM: Eclipse OpenJ9 VM
openjdk version "1.8.0_192"
OpenJDK Runtime Environment (build 1.8.0_192-b12_openj9)
Eclipse OpenJ9 VM (build openj9-0.11.0, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20181107_95 (JIT enabled, AOT enabled)
OpenJ9 - 090ff9dcd
OMR - ea548a66
JCL - b5a3affe73 based on jdk8u192-b12)

OpenJDK9-OpenJ9 （正确的识别容器限制，3G）安全。

[root@xiaoke-test ~]# docker run -m 4GB --rm adoptopenjdk/openjdk9-openj9:alpine-slim java -XshowSettings:vm -version
VM settings:
Max. Heap Size (Estimated): 3.00G
Using VM: Eclipse OpenJ9 VM
openjdk version "9.0.4-adoptopenjdk"
OpenJDK Runtime Environment (build 9.0.4-adoptopenjdk+12)
Eclipse OpenJ9 VM (build openj9-0.9.0, JRE 9 Linux amd64-64-Bit Compressed References 20180814_248 (JIT enabled, AOT enabled)
OpenJ9 - 24e53631
OMR - fad6bf6e
JCL - feec4d2ae based on jdk-9.0.4+12)

OpenJDK10-OpenJ9 （正确的识别容器限制，3G）安全。

[root@xiaoke-test ~]# docker run -m 4GB --rm adoptopenjdk/openjdk10-openj9:alpine-slim java -XshowSettings:vm -version
VM settings:
Max. Heap Size (Estimated): 3.00G
Using VM: Eclipse OpenJ9 VM
openjdk version "10.0.2-adoptopenjdk" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2-adoptopenjdk+13)
Eclipse OpenJ9 VM (build openj9-0.9.0, JRE 10 Linux amd64-64-Bit Compressed References 20180813_102 (JIT enabled, AOT enabled)
OpenJ9 - 24e53631
OMR - fad6bf6e
JCL - 7db90eda56 based on jdk-10.0.2+13)

OpenJDK11-OpenJ9（正确的识别容器限制，3G）安全。

[root@xiaoke-test ~]# docker run -m 4GB --rm adoptopenjdk/openjdk11-openj9:alpine-slim java -XshowSettings:vm -version
VM settings:
Max. Heap Size (Estimated): 3.00G
Using VM: Eclipse OpenJ9 VM
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.1+13)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.11.0, JRE 11 Linux amd64-64-Bit Compressed References 20181020_70 (JIT enabled, AOT enabled)
OpenJ9 - 090ff9dc
OMR - ea548a66
JCL - f62696f378 based on jdk-11.0.1+13)

分析

分析之前我们先了解这么一个情况：

JavaMemory (MaxRAM) = 元数据+线程+代码缓存+OffHeap+Heap...

一般我们都只配置Heap即使用-Xmx来指定JVM可使用的最大堆。而JVM默认会使用它获取到的最大内存的1/4作为堆的原因也是如此。

安全性（即不会超过容器限制被容器kill）

OpenJDK：

OpenJdk8-12，都能保证这个安全性的特点（8和9需要特殊参数，-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap）。

OpenJ9：

2.IbmOpenJ9所有的版本都能识别到容器限制。

资源利用率

OpenJDK：

自动识别到容器限制后，OpenJDK把最大堆设置为了大概容器内存的1/4，对内存的浪费不可谓不大。

当然可以配合另一个JVM参数来配置最大堆。-XX:MaxRAMFraction=int。下面是我整理的一个常见内存设置的表格，从中我们可以看到似乎JVM默认的最大堆的取值为MaxRAMFraction=4，随着内存的增加，堆的闲置空间越来越大，在16G容器内存时，Java堆只有不到4G。

MaxRAMFraction取值 堆占比 容器内存=1G 容器内存=2G 容器内存=4G 容器内存=8G 容器内存=16G
1 ≈90% 910.50M 1.78G 3.56G 7.11G 14.22G
2 ≈50% 455.50M 910.50M 1.78G 3.56G 7.11G
3 ≈33% 304.00M 608.00M 1.19G 2.37G 4.74G
4 ≈25% 228.00M 455.50M 910.50M 1.78G 3.56G

OpenJ9：

关于OpenJ9的的详细介绍你可以从这里了解更多。

对于内存利用率OpenJ9的策略是优于OpenJDK的。以下是OpenJ9的策略表格.

容器内存&lt;size&gt; 最大Java堆大小
小于1 GB 50％&lt;size&gt;
1 GB - 2 GB &lt;size&gt; - 512 MB
大于2 GB 大于2 GB

结论

注意：这里我们说的是容器内存限制，和物理机内存不同。

自动档

如果你想要的是，不显示的指定-Xmx，让Java进程自动的发现容器限制。

如果你想要的是JVM进程在容器中安全稳定的运行，不被容器kiil，并且你的JDK版本小于10（大于等于JDK10的版本不需要设置，参考前面的测试）。

你需要额外设置JVM参数-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap，即可保证你的Java进程不会因为内存问题被容器Kill。

当然这个方式使用起来简单，可靠，缺点也很明显，资源利用率过低（参考前面的表格MaxRAMFraction=4）。

如果想在基础上我还想提高一些内存资源利用率，并且容器内存为1GB - 4GB，我建议你设置-XX:MaxRAMFraction=2，在大于8G的可以尝试设置-XX:MaxRAMFraction=1（参考上表格）。

手动挡

如果你想要的是手动挡的体验，更加进一步的利用内存资源，那么你可能需要回到手动配置时代-Xmx。

手动挡部分，请可以完全忽略上面我的BB。

上面我们说到了自动挡的配置，用起来很简单很舒服，自动发现容器限制，无需担心和思考去配置-Xmx。

比如你有内存1G那么我建议你的-Xmx750M，2G建议配置-Xmx1700M，4G建议配置-Xmx3500-3700M，8G建议设置-Xmx7500-7600M，总之就是至少保留300M以上的内存留给JVM的其他内存。如果堆特别大，可以预留到1G甚至2G。

手动挡用起来就没有那么舒服了，当然资源利用率相对而言就更高了。

原文：https://qingmu.io/2018/12/17/How-to-securely-limit-JVM-resources-in-a-container/

docker jvm 容器技术 docker命令容器 openjdk

安科网

技术进阶：Docker容器中的JVM资源该如何被安全的限制？

GluttonousZX

GluttonousZX

相关推荐

IT工程师都需要掌握的容器技术之Dockerfile

IT工程师都需要掌握的容器技术之Docker存储管理

Docker使用Portainer搭建可视化界面的方法

docker容器与宿主机的数据交互方式总结

如何进入、退出docker的container实现

详解docker pull 下来的镜像都存到了哪里

优化Docker镜像，加速应用部署，教你几个小窍门

Docker不再是唯一的选择

Docker 卷到底是个啥玩意？从使用到深入！

推荐给IT新手的11个Docker免费上手项目

10个冷门但又非常实用的Docker使用技巧

谁说前端不用懂，手摸手 Docker 从入门到实践

docker镜像制作

Docker 容器监控方案怎么选？看看这套开源方案

Node.js web 应用如何封装到Docker容器中

deepin apt命令安装最新版本的docker的方法

还不使用Docker管理数据，你是从1985年穿越来的吗？

如何使用Docker容器化Node.js应用程序

Docker Swarm概念与基本用法

优化 Docker 镜像大小常见方法

GluttonousZX