HannesWell
commented
1 week ago After a few more experiments with explicitly set heap-sizes even with -Xmx1G the build succeeded. While setting -Xmx8G -Xms4G lead to the 'known' obscure <some number> Killed error messages.
My explanation for this is that since the max heap limit was set to 4GiB the JVM respectively GC exhausted that limit, became lazy to collect garbage in the heap and just grew the heap. As soon as the memory demand of the JVM in total (which needs besides the heap also native memory for class data, string constants, etc. and its own execution) plus the demand of other programs running exceeded the 4GiB of the executor the script step was canceled respectively the maven execution killed.
Since by default the VM argument -XX:MaxRAMPercentage is set to 25(%) of the RAM available in total, just removing the explicit
MAVEN_OPTS is equivalent to specify -Xmx1G. One can verify that by passing -XX:+PrintFlagsFinal.
In case the implicitly set -Xmx1G is not sufficient after all, the Maven JVM will now throw an OutOfMemoryError (which at least can be dumped and analyzed quite easy) and we can still double the heap to -Xmx2G and should still leave sufficient memory for others.
I have also investigated where the previous value was coming from and it was set from the very beginning when the Jenkinsfile was created. I assume it was set without any specific need just to be 'on the save side' to avoid OOMErrors.
Hopefully this (surprisingly simple) fix will make these obscure <some number> Killed aborts a relic of the past.
If anyone still encounters them (or encounters OOMErrors) please let me know.
jukzi
Test Results
466 files ±0 466 suites ±0 7m 54s :stopwatch: +10s 4 133 tests ±0 4 125 :white_check_mark: ±0 8 :zzz: ±0 0 :x: ±0 16 328 runs ±0 16 236 :white_check_mark: ±0 92 :zzz: ±0 0 :x: ±0
Results for commit 02a601bf. ± Comparison against base commit 2e835216.
:recycle: This comment has been updated with latest results.