Adam Saghy created FINERACT-2812:
------------------------------------
Summary: Github Actions memory optimization
Key: FINERACT-2812
URL: https://issues.apache.org/jira/browse/FINERACT-2812
Project: Apache Fineract
Issue Type: Improvement
Affects Versions: 1.15.0
Reporter: Adam Saghy
Assignee: Adam Saghy
Fix For: 1.16.0
h3. Changes
*Test JVM cap → 4g* (build.gradle:747). {{:fineract-provider}} keeps its own
explicit 2g — its suite is the largest and I'd already confirmed it passes
there, so there was no reason to loosen it.
*Cargo Tomcat capped at 2g* in integration-tests, oauth2-tests and
twofactor-tests. This was the genuinely unbounded one: {{-Xmx2G}} previously
only appeared on the {{localDebug}} path in {{{}integration-tests{}}}, and not
at all in the other two, so in CI the server inherited ~4g. I also dropped the
now-duplicate {{-Xmx2G}} from the {{localDebug}} branch — local debug behaviour
is unchanged, the value just comes from the shared line.
h3. Confirmed by evaluating the build
:fineract-provider test.maxHeapSize=2g :integration-tests test.maxHeapSize=4g
cargo -Xmx2G :oauth2-tests test.maxHeapSize=4g cargo -Xmx2G :twofactor-tests
test.maxHeapSize=4g cargo -Xmx2G :fineract-core test.maxHeapSize=4g
Exactly one {{-Xmx}} per cargo args string, and {{rat spotlessCheck}} passes.
h3. Resulting budget
||Component||Cap||Set in||
|Gradle build JVM — local|8g|{{gradle.properties}}|
|Gradle build JVM — CI|4g (6g sonar, 2g the three {{devRun}}
jobs)|{{gradle-memory-budget}}|
|{{org.gradle.workers.max}} — CI|2|{{gradle-memory-budget}}|
|Forked {{javac}}|2g each|{{build.gradle}}|
|SpotBugs worker|2g|{{build.gradle}}|
|Forked test JVM|4g (provider 2g)|{{build.gradle}}|
|Cargo Tomcat|2g|the three cargo modules|
|Dockerised backend|1g|{{fineract-common.env}} (pre-existing)|
|{{{}devRun{}}}/{{{}bootRun{}}} backend|3g|per-step {{JAVA_TOOL_OPTIONS}}|
|E2E cucumber JVM|2g|per-step {{JAVA_TOOL_OPTIONS}}|
Peaks on a 16 GB runner: {{run-integration-test-sequentially}} *14g* (4 + 2×4 +
2, down from a 20g ceiling with nothing capped), the DB/Docker test jobs ~11g,
{{regression-safety}} ~11g, quality checks 8g.
That 14g job is the only one without comfortable headroom. If it ever gets
OOM-killed, the fix is {{workers-max: '1'}} in its budget step → 10g; I left it
at 2 rather than fully serialize the longest suite in the pipeline.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
