[che-worspaces] Tune OpenJDK JVM flags so as to use less memory. #79
Conversation
- Set CHE_WORKSPACE_MAVEN_OPTIONS so as to set -Xmx to the same value the builders use. See fabric8io/fabric8-pipeline-library#362 - Set preferred GC options for small JVMs, don't memory map JAR files, and make the JVM use the CGroup container limit rather than the hosts physical memory which, together with 32 bit OpenJDK, reduce memory footprint of che workspaces up to 50% as determined by VmRSS. - Reduce container memory limit to 1200Mi (from 1900Mi) since it continues to work fine with the above tunings in place. In fact, my testing showed that the tuned headroom left will be larger than for the original 1900Mi limit for the same use-cases.
|
32 bit OpenJDK equivalent of #73. In my testing I've seen up to 50% less memory being used as compared to the current setup on OSIO. This matches what we've seen elsewhere. This PR depends on https://github.com/redhat-developer/che-dockerfiles/pull/29 and can be tested with a config like this: redhat-developer/rh-che@master...jerboaa:32bit_openjdk_stacks Those images are vertx/spring-boot stack builds with 32 bit OpenJDK. |
|
Vert.x workspace with this: Spring-boot workspaces with this: |
|
@jerboaa that's fantastic! Will test it asap ;-) Have you tried if we are able to build and run Che itself with these settings? |
|
@l0rd I have not. I don't see why it shouldn't be possible, though. With some tweaks, that is. |
|
I think this is outdated. Che JVM is multiuser now |
value the builders use. See
Improve maven builder setup. fabric8io/fabric8-pipeline-library#362
JAR files, and make the JVM use the CGroup container limit rather
than the hosts physical memory which, together with 32 bit OpenJDK,
reduce memory footprint of che workspaces up to 50% as determined
by VmRSS.
continues to work fine with the above tunings in place. In fact,
my testing showed that the tuned headroom left will be larger
than for the original 1900Mi limit for the same use-cases.