[
https://issues.apache.org/jira/browse/FINERACT-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Saghy resolved FINERACT-2812.
----------------------------------
Resolution: Fixed
> 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
> Priority: Major
> 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)
