OpenJDK and Containers
What can be done to help the OpenJDK JVM play well in the world of Linux Containers?
I thought I’d start tackling this issue by answering some frequently asked questions:
Why is it when I specify -Xmx=1g my JVM uses up more memory than 1gb of memory?
Specifying -Xmx=1g is telling the JVM to allocate a 1gb heap. It’s not telling the JVM to limit its entire memory usage to 1gb. There are card tables, code caches, and all sorts of other off heap data structures. The parameter you use to specify total memory usage is -XX:MaxRAM. Be aware that with -XX:MaxRam=500m your heap will be approximately 250mb.
Why is it when I specify -m 10m to my Linux container the JVM appears to ignore the limit?
The JVM historically looked in /proc to figure out how much memory was available and then set its heap size based on that value. Unfortunately, containers like Docker don’t provide container specific information in /proc. I’ve proposed a patch which has been accepted upstream to provide a -XX:+UseCGroupMemoryLimitForHeap command line argument which tells the JVM to look in /sys/fs/cgroup/memory/memory.limit_in_bytes to figure out how much memory is available. If this patch isn’t available in the OpenJDK version you are running you can simulate it by setting -XX:MaxRAM=n explicitly.
Get the Red Hat Developer Studio Tools
A development environment with superior support for your entire development lifecycle.START CODING TODAY
What if I specify cpusets?
There is a patch in OpenJDK8, which will use the information available to the cgroup to calculate the appropriate number of parallel GC threads. However, if this patch is not available in your version of OpenJDK you may end up with 8 parallel GC threads and only 2 cpus in your container. The workaround is to specify the number of parallel gc threads explicitly. -XX:ParallelGCThreads=2. If you only have 1 CPU in your container I highly recommend that you run with -XX:+UseSerialGC and avoid parallel GC altogether.
OK, so I know I can explicitly set things like heap size and parallel gc threads, but how can I tell the JVM I don’t care about pause time or throughput I just want it to use as few resources as possible?
-XX:+UseSerialGC will run with only 1 garbage collection thread and will run with the smallest heap overhead.
-XX:+TieredCompilation -XX:TieredStopAtLevel=1 will disable the optimizing compiler and save some space.
My program has a startup phase where it needs a lot of heap but will settle into a quiet looping phase where it doesn’t need as much. Can I configure the heap to grow, shrink, and give memory it isn’t currently using back to the operating system?
SerialGC will do this for you, but you can ask it to be more aggressive.
-XX:MinHeapFreeRatio=20 (This defaults to Grow when the heap is greater than 80% occupied)
-XX:MaxHeapFreeRatio=40 (Shrink when the heap is less than 60% occupied).
Parallel GC will do this for you as well. We recommend the following additional parameters:
OK, I have a 2gb heap, and my jvm instance is using 4gb, where are the other 2gb going?
You can track native memory by running Java with the following command line arguments:
java -XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=”summary” -XX:+PrintNMTStatistics
You can decrease some of these parameters. If you are running with many threads, for example, decreasing the size of your Java thread stacks might help. -Xss228k will decrease the size of your Java stacks.
|-XX:+UseSerialGC||Uses only 1 GC thread. This both limits the cpu instruction count for garbage collection, but also results in the minimal memory footprint.|
|-XX:MaxRAM=n||Sets the maximum amount of memory used by the JVM to n, where n may be expressed in terms of megabytes 100m or gigabytes 2g.|
|-XX:+UseCGroupMemoryLimitForHeap||This flag present in the more recent builds of JDK8 tells the JVM to use the information in /sys/fs/cgroup/memory/memory.limit_in_bytes to calculate memory defaults.|
|-XX:ParallelGCThreads=n||Set the number of parallel GC threads to n. This is helpful if you are trying to limit the cpu usage of your container, or if you are running with a JVM that doesn’t include the patch to calculate GC threads based on processors available to the cgroup.|
|Turns off the optimizing compiler. This can sometimes decrease the footprint of your running JVM.|
|These parameters tell the heap to shrink aggressively and to grow conservatively. Thereby optimizing the amount of memory available to the operating system.|
|These parameters are necessary when running parallel GC if you want to use the Min and Max Heap Free ratios.|
|These options will print out the non-heap memory usage of your JVM.|
|-Xss228k||This will decrease the size of your Java Stacks.|
If you have any additional questions, please drop me an email: email@example.com.
To learn more, visit our Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets (e.g. containers), books (e.g. microservices), and product downloads that can help you with your microservices and/or container application development.