Java 8 had not a good compatibility with Docker, now the problem has disappeared.
Note: I use the GNU GPL v2 license using the OpenJDK official docker image in this article. In the Oracle Java SE, docker support functions described here introduced in the update 191. Oracle to change the license Java 8 updated in April 2019, since Java SE 8 Update 211 since the commercial use is no longer free.
Have you encountered appear on the JVM applications "random" run error docker in? Or perhaps some strange crashes? Both of which may be Java 8 (still widely used) in support due to bad docker.
Docker using a control group (cgroups) to limit resource. Limit memory and CPU when running applications in the container is definitely a good idea - it can prevent the application occupy the entire available memory and / or CPU, which can result in other containers running on a system with no response. Resource constraints can improve the reliability and stability of the application. It also allows to make hardware capacity planning. The container is especially important when running on a scheduling system Kubernetes or DC / OS or the like.
problem
JVM can "see" across all CPU cores and memory available on the system, and to ensure consistent resources. It will default maximum heap size (heap size) is set to 1/4 of system memory, and some thread pool size (such as for GC) is set to the number of physical core. Look at an example.
We will run a simple application, it consumes as much memory (can be found on the website):
We run on systems with 64GB of memory, so you can check the default maximum heap size:
As described above, it is the physical memory that is 1/4 of 16GB. If we use docker cgroups memory limitations, what would happen? You may wish to check:
JVM process is killed. Because it is a child process - the container itself survived, but usually when java is the only process in the container (PID 1), the container will collapse.
Wish-depth look at the system log:
Like such a failure can be difficult to debug - Application Log nothing. Especially difficult AWS ECS on managed systems and the like.
How about CPU? May wish to check again, display the available number of processors to run a small program:
You may wish to run it docker container 1 cpu number in a set:
Well, there are 12 CPU on this system. Thus, even if the number of available processors is limited to 1, JVM will try to use 12-- example, the GC is set by the number of threads of the formula:
On machines with hardware threads N (N greater than 8), the parallel collector using a fixed number of fractional-N as garbage collector thread. If the value of N is large, the fraction 5/8. If the value of N is less than 8, using a number N.
In our case:
solution
OK, we are now aware of the problem. There is a solution? Fortunately, there is!
The new version of Java (10 and above) has built docker support. But sometimes the upgrade is not the answer, for example, if the application is not compatible with the new JVM can not.
The good news: Docker support has also been ported back to Java 8. You may wish to check the mark-to-date image 8u212 of openjdk. Our memory is limited to 1G, and use a CPU: docker run -ti --cpus 1 -m 1G openjdk: 8u212-jdk.
RAM:
It is 256M, is just 1/4 of allocated memory.
CPU：
As we want to be.
In addition, there are several new settings:
They allow fine-tuning the heap size - the meaning of these settings in this excellent answer to the StackOverflow has been explained. Note: They set a percentage, rather than a fixed value. Because of this change Docker memory settings will not break anything.
If for some reason do not want to see the new JVM behavior, you can use -XX: -UseContainerSupport to close.
to sum up
JVM based applications to set the correct heap size is extremely important. If you are using the latest version of Java 8, you can rely on the security (but very conservative) default settings. Without using any workaround docker entry point, then Xmx not necessary to set a fixed value.
Use JVM happy!