JVM Memory settings best practice

Xms = Xmx

On your instance, initial heap size is pretty small, only 1Gb. When free heap space is getting low, JVM memory allocator usually runs a garbage collection phase before increasing heap size. During this GC phase, it can free up some soft references, and for Jenkins this means valuable build data. When you requested the support bundle, JVM had only allocated 3Gb of heap memory, much less than the maximum requested size specified with Xmx argument. In your case, I would suggest to increase initial heap size to ensure build data are not needlessly freed up.

As a general rule, it makes sense on a dedicated server to set identical value for Xms and Xmx parameters. System memory is big enough to host a JVM with a heap as big as specified with Xmx so it’s just a waste of system memory to keep memory available to the OS but not to the JVM.

Garbage collection can pause JVM for a long time on a big heap. Hence, we usually suggest to use G1GC on heap bigger than 4Gb.

MaxPermSize 256m minimum

Disabling THP

cat /sys/kernel/mm/redhat_transparent_hugepage/enabled

cat /sys/kernel/mm/transparent_hugepage/enabled

 

Some links:

http://www.slideshare.net/SimonRitter/low-latencyapps

http://java-is-the-new-c.blogspot.fr/2013/07/tuning-and-benchmarking-java-7s-garbage.html

 

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.