From 54ef5cb61510f98b92e48f2a052f105caaf66aec Mon Sep 17 00:00:00 2001 From: Inaki Fernandez Date: Fri, 15 May 2020 16:37:04 +0200 Subject: [PATCH] markdown test --- docs/jvm-parameters-matrix-table.md | 30 ++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/docs/jvm-parameters-matrix-table.md b/docs/jvm-parameters-matrix-table.md index 16a0434c..fc7ccc67 100644 --- a/docs/jvm-parameters-matrix-table.md +++ b/docs/jvm-parameters-matrix-table.md @@ -1,16 +1,16 @@ | **JVM Parameter** | **Enable?** | **References / Details** | -| :----------------------------------|:---|:---| -| -XX:+UseG1GC | Enabled by default in Java 8u191+ | Most important defaults specific to G1 and their default values.
https://dzone.com/articles/choosing-the-right-gc
https://wiki.openjdk.java.net/display/HotSpot/G1GC+Feedback
Alternative: Shenandoah GC | -| -XX:+UseShenandoahGC | Alternative to G1GC. | Shenandoah Garbage Collector: experimental in Java 8, newer than G1GC, available in some OpenJDK 8 and newer releases.
https://wiki.openjdk.java.net/display/shenandoah/Main
https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1 | -| -XX:+UseZGC | Yes (JDK 11+) | Z GC : Better Garbage Collector Algorithm than G1 or Shenandoah. JDK 11+ required.
The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector designed to meet the following goals:
· Pause times do not exceed 10ms (*)
· Pause times do not increase with the heap or live-set size
· Handle heaps ranging from a 8MB to 16TB in size
At a glance, ZGC is:
· Concurrent
· Region-based
· Compacting
· NUMA-aware
· Using colored pointers
· Using load barriers
At its core, ZGC is a concurrent garbage collector, meaning all heavy lifting work is done while Java threads continue to execute. This greatly limits the impact garbage collection will have on your application's response time.
7 JVM Arguments of Highly Effective Applications
https://wiki.openjdk.java.net/display/zgc/Main | -| -XX:MaxRAMPercentage | Yes | Java 8u191+ required.
The old (and somewhat broken) flags -XX:{Min\|Max}RAMFraction are now deprecated.
There is a new flag -XX:MaxRAMPercentage, that takes a value between 0.0 and 100.0 and defaults to 25.0.
So if there is a 1 GB memory limit, the JVM heap is limited to ~250 MB by default.
While this can certainly be improved — depending on the RAM size and workload — it’s a pretty good default compared to the old behaviour.
https://medium.com/adorsys/usecontainersupport-to-the-rescue-e77d6cfea712 | -| -XX:+UseContainerSupport | Enabled by default | Java 8u191+ required (enabled by default in Linux)
https://medium.com/adorsys/jvm-memory-settings-in-a-container-environment-64b0840e1d9e
https://medium.com/adorsys/usecontainersupport-to-the-rescue-e77d6cfea712
Please note that setting -Xmx and -Xms disables the automatic heap sizing.
# check if +UseContainerSupport is enabled
$ java -XX:+PrintFlagsFinal -version | grep UseContainerSupport
bool UseContainerSupport = true {product}
https://merikan.com/2019/04/jvm-in-a-container/
Java 10 introduced +UseContainerSupport (enabled by default) which makes the JVM use sane defaults in a container environment.
This feature is backported to Java 8 since 8u191, potentially allowing a huge percentage of Java deployments in the wild to properly configure their memory. | -| -XshowSettings:vm | Yes | This is a priceless feature to display all the settings of the JVM, together with -XX:+PrintCommandLineFlags it can show a world of hidden stuff.
http://www.javamonamour.org/2018/11/java-showsettings.html | -| -XX:MaxRAMFraction | No (deprecated) | Requires JDK 8u131+
-XX:MaxRAMFraction deprecated since Java 8u191+ (use -XX:MaxRAMPercentage instead)
https://dzone.com/articles/running-a-jvm-in-a-container-without-getting-kille
https://developers.redhat.com/blog/2017/03/14/java-inside-docker/
https://merikan.com/2019/04/jvm-in-a-container/ | -| -XX:+UseCGroupMemoryLimitForHeap | No (deprecated) | JDK 8u131+ required
Deprecated in Java10 & Java8u191+
https://dzone.com/articles/running-a-jvm-in-a-container-without-getting-kille
https://developers.redhat.com/blog/2017/03/14/java-inside-docker/
https://merikan.com/2019/04/jvm-in-a-container/
Java memory management and configuration is still complex. Although the JVM can read cgroup memory limits and adapt memory usage accordingly since Java 9/8u131,
it’s not a golden bullet. You need to know what -XX:+UseCGroupMemoryLimitForHeap does and you need to fine tune some parameters for every deployment.
Otherwise you risk wasting resources and money or getting your containers killed at the worst time possible. -XX:MaxRAMFraction=1 is especially dangerous.
Java 10+ brings a lot of improvements but still needs manual configuration. To be safe, load test your stuff. | -| *-XX:+UseStringDeduplication* | Yes | https://www.baeldung.com/jvm-garbage-collectors | -| -XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath | Yes | When running a JVM in a docker container it is probably wise to use the HeapDumpOnOutOfMemoryError option so if you ever run out of memmory the jvm will write a dump of the heap to disk.
https://merikan.com/2019/04/jvm-in-a-container/
https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1 | -| -Xss | Test | Increase the thread’s stack size limit by passing the -Xss argument.
https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1
Each application will have tens, hundreds, thousands of threads. Each thread will have its own stack. Each one of them consumes memory.
If their consumption goes beyond a certain limit, then a StackOverflowError is thrown. More details about StackOverflowError and solutions to resolve it can be found in this article.
Linux 64-bit JVM Default thread stack size = 1024k
-Xss2m : This will set the thread's stack size to 2mb | -| -Dsun.net.client.defaultConnectTimeout
-Dsun.net.client.defaultReadTimeout | Yes | https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1 | -| -Duser.timeZone | Yes | https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1 | -| Enable GC Logging | Check | JDK 8: -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:{file-path}
JDK9+: -Xlog:gc*:file={file-path}
https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1 | +|:----------------------------------|:---|:---| +|-XX:+UseG1GC | Enabled by default in Java 8u191+ | Most important defaults specific to G1 and their default values.
https://dzone.com/articles/choosing-the-right-gc
https://wiki.openjdk.java.net/display/HotSpot/G1GC+Feedback
Alternative: Shenandoah GC | +|-XX:+UseShenandoahGC | Alternative to G1GC. | Shenandoah Garbage Collector: experimental in Java 8, newer than G1GC, available in some OpenJDK 8 and newer releases.
https://wiki.openjdk.java.net/display/shenandoah/Main
https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1 | +|-XX:+UseZGC | Yes (JDK 11+) | Z GC : Better Garbage Collector Algorithm than G1 or Shenandoah. JDK 11+ required.
The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector designed to meet the following goals:
· Pause times do not exceed 10ms (*)
· Pause times do not increase with the heap or live-set size
· Handle heaps ranging from a 8MB to 16TB in size
At a glance, ZGC is:
· Concurrent
· Region-based
· Compacting
· NUMA-aware
· Using colored pointers
· Using load barriers
At its core, ZGC is a concurrent garbage collector, meaning all heavy lifting work is done while Java threads continue to execute. This greatly limits the impact garbage collection will have on your application's response time.
7 JVM Arguments of Highly Effective Applications
https://wiki.openjdk.java.net/display/zgc/Main | +|-XX:MaxRAMPercentage | Yes | Java 8u191+ required.
The old (and somewhat broken) flags -XX:{Min\|Max}RAMFraction are now deprecated.
There is a new flag -XX:MaxRAMPercentage, that takes a value between 0.0 and 100.0 and defaults to 25.0.
So if there is a 1 GB memory limit, the JVM heap is limited to ~250 MB by default.
While this can certainly be improved — depending on the RAM size and workload — it’s a pretty good default compared to the old behaviour.
https://medium.com/adorsys/usecontainersupport-to-the-rescue-e77d6cfea712 | +|-XX:+UseContainerSupport | Enabled by default | Java 8u191+ required (enabled by default in Linux)
https://medium.com/adorsys/jvm-memory-settings-in-a-container-environment-64b0840e1d9e
https://medium.com/adorsys/usecontainersupport-to-the-rescue-e77d6cfea712
Please note that setting -Xmx and -Xms disables the automatic heap sizing.
# check if +UseContainerSupport is enabled
$ java -XX:+PrintFlagsFinal -version | grep UseContainerSupport
bool UseContainerSupport = true {product}
https://merikan.com/2019/04/jvm-in-a-container/
Java 10 introduced +UseContainerSupport (enabled by default) which makes the JVM use sane defaults in a container environment.
This feature is backported to Java 8 since 8u191, potentially allowing a huge percentage of Java deployments in the wild to properly configure their memory. | +|-XshowSettings:vm | Yes | This is a priceless feature to display all the settings of the JVM, together with -XX:+PrintCommandLineFlags it can show a world of hidden stuff.
http://www.javamonamour.org/2018/11/java-showsettings.html | +|-XX:MaxRAMFraction | No (deprecated) | Requires JDK 8u131+
-XX:MaxRAMFraction deprecated since Java 8u191+ (use -XX:MaxRAMPercentage instead)
https://dzone.com/articles/running-a-jvm-in-a-container-without-getting-kille
https://developers.redhat.com/blog/2017/03/14/java-inside-docker/
https://merikan.com/2019/04/jvm-in-a-container/ | +|-XX:+UseCGroupMemoryLimitForHeap | No (deprecated) | JDK 8u131+ required
Deprecated in Java10 & Java8u191+
https://dzone.com/articles/running-a-jvm-in-a-container-without-getting-kille
https://developers.redhat.com/blog/2017/03/14/java-inside-docker/
https://merikan.com/2019/04/jvm-in-a-container/
Java memory management and configuration is still complex. Although the JVM can read cgroup memory limits and adapt memory usage accordingly since Java 9/8u131,
it’s not a golden bullet. You need to know what -XX:+UseCGroupMemoryLimitForHeap does and you need to fine tune some parameters for every deployment.
Otherwise you risk wasting resources and money or getting your containers killed at the worst time possible. -XX:MaxRAMFraction=1 is especially dangerous.
Java 10+ brings a lot of improvements but still needs manual configuration. To be safe, load test your stuff. | +|-XX:+UseStringDeduplication | Yes | https://www.baeldung.com/jvm-garbage-collectors | +|-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath | Yes | When running a JVM in a docker container it is probably wise to use the HeapDumpOnOutOfMemoryError option so if you ever run out of memmory the jvm will write a dump of the heap to disk.
https://merikan.com/2019/04/jvm-in-a-container/
https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1 | +|-Xss | Test | Increase the thread’s stack size limit by passing the -Xss argument.
https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1
Each application will have tens, hundreds, thousands of threads. Each thread will have its own stack. Each one of them consumes memory.
If their consumption goes beyond a certain limit, then a StackOverflowError is thrown. More details about StackOverflowError and solutions to resolve it can be found in this article.
Linux 64-bit JVM Default thread stack size = 1024k
-Xss2m : This will set the thread's stack size to 2mb | +|-Dsun.net.client.defaultConnectTimeout
-Dsun.net.client.defaultReadTimeout | Yes | https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1 | +|-Duser.timeZone | Yes | https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1 | +|Enable GC Logging | Check | JDK 8: -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:{file-path}
JDK9+: -Xlog:gc*:file={file-path}
https://dzone.com/articles/7-jvm-arguments-of-highly-effective-applications-1 |