-
Bug
-
Resolution: Done
-
Major
-
None
-
None
When using the ubi8/openjdk-11 container, extra JVM parameters are passed
By default our Java applications are started with those options:
exec java -Dquarkus.http.host=0.0.0.0 -Xms256m -Xmx1024m -XX:+UseParallelOldGC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:MaxMetaspaceSize=100m -XX:ParallelGCThreads=1 -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 -XX:CICompilerCount=2 -XX:+ExitOnOutOfMemoryError -cp . -jar /deployments/policies-engine-external-2.1.0-SNAPSHOT-runner.jar
AFAIK those were necessary workarounds hen Java would "look" at the server capacity rather than container capacity, now they seem more harmful.
Our containers would be OOMKilled after a day...
By looking into the container we figured out that if we set:
JAVA_CORE_LIMIT=0 we get rid of some parameters, so that the JVM would start with:
java -Dquarkus.http.host=0.0.0.0 -Xms256m -Xmx1024m -XX:+UseParallelOldGC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:MaxMetaspaceSize=100m -XX:+ExitOnOutOfMemoryError -cp "." -jar /deployments/policies-engine-external-2.1.0-SNAPSHOT-runner.jar
Which is better, our containers could run for as long as we needed until we faced:
"Terminating due to java.lang.OutOfMemoryError: Metaspace"
So now we're looking into removing "-XX:MaxMetaspaceSize=100m"
I think (and OpenJDK team confirmed) that we should just start without JVM parameters and let us add some if we need, rather than trying to hack around to remove parameters.
(Another source of frustration is the addition of Jolokia/Prometheus that AFAIK we don't need for an app using MicroProfile metrics, a very bare image of ubi8+openJDK that is regularly updated is likely what we would prefer)
- is related to
-
OPENJDK-2009 JAVA_OPTS not working on ubi8/openjdk-17
- Closed
- links to