Java服务Docker容器化资源配置
中文说明： 在java版本小于8u191时，使用Xms、Xmx的方式配置堆内存大小，开发人员需要主动管理Xms、Xmx和docker配额的比例。当java版本大于8u191时，可以使用-XX:MinRAMPercentage（默认值50）、-XX:MaxRAMPercentage（默认值25）、-XX:InitialRAMPercentage参数设置java应用堆内存大小。当内存小于250M时，会使用MinRAMPercentage百分比，当内存大于250M时，会使用MaxRAMPercentage比例。如果设置了Xmx则这两个参数无效，同样设置了Xms时-XX:InitialRAMPercentage参数无效。可以根据内存大小适当调整MaxRAMPercentage的比例值，大于2G时，建议75，小于1G时建议50。
1. Overvie
When we run Java within a container, we may wish to tune it to make the best use of the available resources. In this tutorial, we’ll see how to set JVM parameters in a container that runs a Java process. Although the following applies to any JVM setting, we’ll focus on the common -Xmx and -Xms flags. We’ll also look at common issues containerizing programs that run with certain versions of Java and how to set flags in some popular containerized Java applications.
2. Default Heap Settings in Java Containers
The JVM is pretty good at determining appropriate default memory settings. In the past, the JVM was not aware of the memory and CPU allocated to the container. So, Java 10 introduced a new setting: +UseContainerSupport (enabled by default) to fix the root cause, and developers backported the fix to Java 8 in 8u191. The JVM now calculates its memory based on the memory allocated to the container. Java 10 引入了一个新设置：+UseContainerSupport（默认启用）来修复 这个问题，并在 8u191中将修复反向移植到 Java 8 。 However, we may still wish to change the settings from their defaults in certain applications.
2.1. Automatic Memory Calculation
When we don’t set -Xmx and -Xmx parameters, the JVM sizes the heap based on the system specifications. Let’s look at that heap size:
1$ java -XX:+PrintFlagsFinal -version | grep -Ei "maxheapsize|maxram"
This outputs:
1openjdk version "15" 2020-09-15
2OpenJDK Runtime Environment AdoptOpenJDK (build 15+36)
3OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15+36, mixed mode, sharing)
4 size_t MaxHeapSize = 4253024256 {product} {ergonomic}
5 uint64_t MaxRAM = 137438953472 {pd product} {default}
6 uintx MaxRAMFraction = 4 {product} {default}
7 double MaxRAMPercentage = 25.000000 {product} {default}
8 size_t SoftMaxHeapSize = 4253024256 {manageable} {ergonomic}
Here, we see that the JVM sets its heap size to approximately 25% of the available RAM. In this example, it allocated 4GB on a system with 16GB.
For the purposes of testing, let’s create a program that prints the heap sizes in megabytes:
1import java.lang.management.ManagementFactory;
2import java.lang.management.MemoryMXBean;
3
4public class PrintXmxXms {
5 public static void main(String[] args) {
6 int mb = 1024 * 1024;
7 MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();
8 long xmx = memoryBean.getHeapMemoryUsage().getMax() / mb;
9 long xms = memoryBean.getHeapMemoryUsage().getInit() / mb;
10 System.out.println("Initial Memory (xms) : " + xms + "mb");
11 System.out.println("Max Memory (xmx) :" + xmx + "mb");
12 }
13}
Let’s place that program in an empty directory, in a file named PrintXmxXms.java.
We can test it on our host, assuming we have an installed JDK. In a Linux system, we can compile our program and run it from a terminal opened on that directory:
1$ javac ./PrintXmxXms.java
2$ java -cp . PrintXmxXms
On a system with 16Gb of RAM, the output is:
1INFO: Initial Memory (xms) : 254mb
2INFO: Max Memory (xmx) : 4,056mb
Now, let’s try that in some containers.
2.2. Before JDK 8u191
Let’s add the following Dockerfile in the folder that contains our Java program:
1FROM openjdk:8u92-jdk-alpine
2COPY *.java /src/
3RUN mkdir /app \
4 && ls /src \
5 && javac /src/PrintXmxXms.java -d /app
6CMD ["sh", "-c", \
7 "java -version \
8 && java -cp /app PrintXmxXms"]
Here we’re using a container that uses an older version of Java 8, which predates the container support that’s available in more up-to-date versions. Let’s build its image:
1$ docker build -t oldjava .
The CMD line in the Dockerfile is the process that gets executed by default when we run the container. Since we didn’t provide the -Xmx or -Xms JVM flags, the memory settings will be defaulted. Let’s run that container:
1$ docker run --rm -ti oldjava
2openjdk version "1.8.0_92-internal"
3OpenJDK Runtime Environment (build 1.8.0_92-...)
4OpenJDK 64-Bit Server VM (build 25.92-b14, mixed mode)
5Initial Memory (xms) : 198mb
6Max Memory (xmx) : 2814mb
Let’s now constrain the container memory to 1GB.
1$ docker run --rm -ti --memory=1g oldjava
2openjdk version "1.8.0_92-internal"
3OpenJDK Runtime Environment (build 1.8.0_92-...)
4OpenJDK 64-Bit Server VM (build 25.92-b14, mixed mode)
5Initial Memory (xms) : 198mb
6Max Memory (xmx) : 2814mb
As we can see, the output is exactly the same. This proves the older JVM does not respect the container memory allocation.
2.3. After JDK 8u130
With the same test program, let’s use a more up to date JVM 8 by changing the first line of the Dockerfile:
1FROM openjdk:8-jdk-alpine
We can then test it again:
1$ docker build -t newjava .
2$ docker run --rm -ti newjava
3openjdk version "1.8.0_212"
4OpenJDK Runtime Environment (IcedTea 3.12.0) (Alpine 8.212.04-r0)
5OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)
6Initial Memory (xms) : 198mb
7Max Memory (xmx) : 2814mb
Here again, it is using the whole docker host memory to calculate the JVM heap size. However, if we allocate 1GB of RAM to the container:
1$ docker run --rm -ti --memory=1g newjava
2openjdk version "1.8.0_212"
3OpenJDK Runtime Environment (IcedTea 3.12.0) (Alpine 8.212.04-r0)
4OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)
5Initial Memory (xms) : 16mb
6Max Memory (xmx) : 247mb
This time, the JVM calculated the heap size based on the 1GB of RAM available to the container.
Now we understand how the JVM calculates its defaults and why we need an up-to-date JVM to get the correct defaults, let’s look at customizing the settings.
3. Memory Settings in Popular Base Images
3.1 OpenJDK and AdoptOpenJDK
Instead of hard-coding the JVM flags directly on our container’s command, it’s good practice to use an environment variable such as JAVA_OPTS. We use that variable within our Dockerfile, but it can be modified when the container is launched:
1FROM openjdk:8u92-jdk-alpine
2COPY src/ /src/
3RUN mkdir /app \
4 && ls /src \
5 && javac /src/com/baeldung/docker/printxmxxms/PrintXmxXms.java \
6 -d /app
7ENV JAVA_OPTS=""
8CMD java $JAVA_OPTS -cp /app \
9 com.baeldung.docker.printxmxxms.PrintXmxXms
Let’s now build the image:
1$ docker build -t openjdk-java .
We can choose our memory settings at runtime by specifying the JAVA_OPTS environment variable:
1$ docker run --rm -ti -e JAVA_OPTS="-Xms50M -Xmx50M" openjdk-java
2INFO: Initial Memory (xms) : 50mb
3INFO: Max Memory (xmx) : 48mb
We should note that there is a slight difference between the -Xmx parameter and the Max memory reported by the JVM. This is because Xmx sets the maximum size of the memory allocation pool, which includes the heap, the garbage collector’s survivor space, and other pools.
3.2. Tomcat 9
A Tomcat 9 container has its own startup scripts, so to set JVM parameters, we need to work with those scripts.
The bin/catalina.sh script requires us to set the memory parameters in the environment variable CATALINA_OPTS. Let’s first create a war file to deploy to Tomcat. Then, we’ll containerize it using a simple Dockerfile, where we declare the CATALINA_OPTS environment variable:
1FROM tomcat:9.0
2COPY ./target/*.war /usr/local/tomcat/webapps/ROOT.war
3ENV CATALINA_OPTS="-Xms1G -Xmx1G"
Then we build the container image and run it:
1$ docker build -t tomcat .
2$ docker run --name tomcat -d -p 8080:8080 \
3 -e CATALINA_OPTS="-Xms512M -Xmx512M" tomcat
We should note that when we run this, we’re passing a new value to CATALINA_OPTS. If we don’t provide this value, though, we gave some defaults in line 3 of the Dockerfile. We can check the runtime parameters applied and verify that our options -Xmx and -Xms are there:
1$ docker exec -ti tomcat jps -lv
21 org.apache.catalina.startup.Bootstrap <other options...> -Xms512M -Xmx512M
4. Using Build Plugins
Maven and Gradle offer plugins that allow us to create container images without a Dockerfile. The generated images can generally be parameterized at runtime through environment variables.
Let’s look at a few examples.
4.1. Using Spring Boot
Since Spring Boot 2.3, the Spring Boot Maven and Gradle plugins can build an efficient container without a Dockerfile. With Maven, we add them to a <_configuration>_ block within the spring-boot-maven-plugin:
1<?xml version="1.0" encoding="UTF-8"?>
2<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
4 <groupId>com.baeldung.docker</groupId>
5 <artifactId>heapsizing-demo</artifactId>
6 <version>0.0.1-SNAPSHOT</version>
7 <!-- dependencies... -->
8 <build>
9 <plugins>
10 <plugin>
11 <groupId>org.springframework.boot</groupId>
12 <artifactId>spring-boot-maven-plugin</artifactId>
13 <configuration>
14 <image>
15 <name>heapsizing-demo</name>
16 </image>
17 <!--
18 for more options, check:
19 https://docs.spring.io/spring-boot/docs/2.4.2/maven-plugin/reference/htmlsingle/#build-image
20 -->
21 </configuration>
22 </plugin>
23 </plugins>
24 </build>
25</project>
To build the project, run:
1$ ./mvnw clean spring-boot:build-image
This will result in an image named :. In this example demo-app:0.0.1-SNAPSHOT. Under the hood, Spring Boot uses Cloud Native Buildpacks as the underlying containerization technology.
The plugin hard-codes the memory settings of the JVM. However, we can still override them by setting the environment variables JAVA_OPTS or JAVA_TOOL_OPTIONS:
1$ docker run --rm -ti -p 8080:8080 \
2 -e JAVA_TOOL_OPTIONS="-Xms20M -Xmx20M" \
3 --memory=1024M heapsizing-demo:0.0.1-SNAPSHOT
The output will be similar to this:
1Setting Active Processor Count to 8
2Calculated JVM Memory Configuration: [...]
3[...]
4Picked up JAVA_TOOL_OPTIONS: -Xms20M -Xmx20M
5[...]
4.2. Using Google JIB
Just like the Spring Boot maven plugin, Google JIB creates efficient Docker images without a Dockerfile. The Maven and Gradle plugins are configured in a similar fashion. Google JIB also uses the environment variable JAVA_TOOL_OPTIONS as the JVM parameters’ overriding mechanism.
We can use the Google JIB Maven plugin in any Java framework capable of generating executable jar files. For example, it’s possible to use it in a Spring Boot application in place of the spring-boot-maven plugin to generate container images:
1<?xml version="1.0" encoding="UTF-8"?>
2<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
4
5 <!-- dependencies, ... -->
6
7 <build>
8 <plugins>
9 <!-- [ other plugins ] -->
10 <plugin>
11 <groupId>com.google.cloud.tools</groupId>
12 <artifactId>jib-maven-plugin</artifactId>
13 <version>2.7.1</version>
14 <configuration>
15 <to>
16 <image>heapsizing-demo-jib</image>
17 </to>
18 </configuration>
19 </plugin>
20 </plugins>
21 </build>
22</project>
The image is built using the maven jib:DockerBuild target:
1$ mvn clean install && mvn jib:dockerBuild
We can now run it as usual:
1$ docker run --rm -ti -p 8080:8080 \
2-e JAVA_TOOL_OPTIONS="-Xms50M -Xmx50M" heapsizing-demo-jib
3Picked up JAVA_TOOL_OPTIONS: -Xms50M -Xmx50M
4[...]
52021-01-25 17:46:44.070 INFO 1 --- [ main] c.baeldung.docker.XmxXmsDemoApplication : Started XmxXmsDemoApplication in 1.666 seconds (JVM running for 2.104)
62021-01-25 17:46:44.075 INFO 1 --- [ main] c.baeldung.docker.XmxXmsDemoApplication : Initial Memory (xms) : 50mb
72021-01-25 17:46:44.075 INFO 1 --- [ main] c.baeldung.docker.XmxXmsDemoApplication : Max Memory (xmx) : 50mb
5. Conclusion
In this article, we covered the need to use an up-to-date JVM to get default memory settings that work well in a container.
We then looked at best practices for setting -Xms and -Xmx in custom container images and how to work with existing Java application containers to set the JVM options in them.
Finally, we saw how to advantage of build tools to manage the containerization of a Java application.
As always, the source code for the examples is available over on GitHub.
Reference page： IBM UseContainerSupport
捐赠本站(Donate)
如您感觉文章有用，可扫码捐赠本站！(If the article useful, you can scan the QR code to donate))
- Author: shisekong
- Link: https://blog.361way.com/java-docker-heap-size/6907.html
- License: This work is under a 知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议. Kindly fulfill the requirements of the aforementioned License when adapting or creating a derivative of this work.