Fix daily native build by limiting Java heap used and spread load in matrix

[michalvavrik]

Summary

• Currently native analytics daily build fails over OOM during native executable build, it started to happen after Use OpenTelemetry extension in Build-tiime Analytics module as OpenTracing is deprecated and not released yet #1520 but I don't expect there is something wrong about OpenTelemetry, it might be larger than OpenTracing extension, but we definitely had problemw with memory in this module before: Propagate max Java heap used during native image generation down to build time analytics app builder #1349
• I checked and Security profile takes least on average (~ 1 h 20 min) and root modules with spring takes up to for 4 h https://github.com/quarkus-qe/quarkus-test-suite/actions/runs/6765196692/job/18392571155 but it jumps heavily with hours in difference). IMO we should spread load by moving Spring modules to Security modules

2023-11-16T03:28:34.0733613Z 03:28:34,030 INFO   - 4.44GB of memory (28.5% of 15.61GB system memory, set via '-Xmx5g')
2023-11-16T03:28:34.0734917Z 03:28:34,030 INFO   - 4 thread(s) (100.0% of 4 available processor(s), determined at start)
2023-11-16T03:35:32.9806773Z 03:35:32,969 INFO  Terminating due to java.lang.OutOfMemoryError: GC overhead limit exceeded

IIUC https://www.graalvm.org/latest/reference-manual/native-image/optimizations-and-performance/MemoryManagement/ it says that GC also needs 2x of the maximum heap size is the worst case and https://quarkus.io/guides/native-reference says minimum allowed is 4 GB.

So this PR might slower down native CI execution, but GH runners seems weak, I suggest to try it and optimize based on results.

Please select the relevant options.

• Bug fix (non-breaking change which fixes an issue)
• Dependency update
• Refactoring
• Backport
• New scenario (non-breaking change which adds functionality)
• This change requires a documentation update
• This change requires execution against OCP (use run tests phrase in comment)

Checklist:

• Methods and classes used in PR scenarios are meaningful
• Commits are well encapsulated and follow the best practices

[michalvavrik]

PS: this CI isn't really testing this PR :-) but let's wait at least for validation (thought that's not testing this PR either)...

[jsmrcka]

Well, it looks like it's worth a shot. Thanks for the analysis.

[michalvavrik]

Well, it looks like it's worth a shot. Thanks for the analysis.

Yeah, it's not worth testing it because native run execution time is really volatile, IMO we need to take a bit of guessing and wait.