Uh oh!
There was an error while loading. Please reload this page.
[SPARK-45651][BUILD][FOLLOWUP] Reduce mvn -Xmx option to 2g in publish_snapshot workflow - #43538
[SPARK-45651][BUILD][FOLLOWUP] Reduce mvn -Xmx option to 2g in publish_snapshot workflow#43538EnricoMi wants to merge 1 commit into
Conversation
EnricoMi
commented
Oct 26, 2023
| cd .. | ||
| export MAVEN_OPTS="-Xss128m -Xmx12g -XX:ReservedCodeCacheSize=1g" | ||
| export MAVEN_OPTS="-Xss128m -Xmx${MAVEN_MXM_OPT:-12g} -XX:ReservedCodeCacheSize=1g" |
There was a problem hiding this comment.
Ok, I previously changed the -Xmx option to 3g in build/mvn script, not here, so the previous fix probably didn't take effect...
There was a problem hiding this comment.
So perhaps the -Xmx here could be larger.
There was a problem hiding this comment.
so the previous fix probably didn't take effect...
I suspect so. The memory logging that is currently in place will tell us for sure if any attempt has any or just too little effect.
There was a problem hiding this comment.
So perhaps the -Xmx here could be larger.
Why so? Do you refer to the 12g in this line or the 2g in the workflow? Since the build workflow uses 2g already, we should stick to those 2g for consistency or bump the 2g in build.yml to 3g as well.
There was a problem hiding this comment.
What I mean is perhaps MAVEN_MXM_OPT could be 4g, because I've tested before and java-other-versions can also run successfully on GA with 4g.
But 2g is also fine to me.
There was a problem hiding this comment.
Understood, either of 2g, 3g, and 4g is fine with me, too.
HyukjinKwon
commented
Oct 27, 2023
Merged to master. |
HyukjinKwon
commented
Oct 27, 2023
Seems not working (https://github.com/apache/spark/actions/runs/6661131541/job/18103495351). I reverted this for now. |
HyukjinKwon
commented
Oct 27, 2023
For now, we use a different Docker image between the actual test and snapshot build. We cache the image (see |
EnricoMi
commented
Oct 27, 2023
The problem was unrelated: |
EnricoMi
commented
Oct 27, 2023
That workflow run did not pick up the changes of this PR: |
In fact, you manually triggered the publish, and it worked perfectly fine for Branch |
LuciferYang
commented
Oct 27, 2023
Shall we revive this pr and give it another try ... |
EnricoMi
commented
Oct 27, 2023
Yes, please! |
EnricoMi
commented
Oct 27, 2023
The mem statistics with So even with |
HyukjinKwon
commented
Oct 27, 2023
I manually triggered once more at https://github.com/apache/spark/actions/runs/6661389655 and it failed too. Is that also unrelated? |
EnricoMi
commented
Oct 27, 2023
Revived in #43555. |
HyukjinKwon
commented
Oct 27, 2023
If that's the case we can get this in again and see if it works. |
HyukjinKwon
commented
Oct 27, 2023
(sorry it's my phone now so can't properly check the logs on my own) |
EnricoMi
commented
Oct 27, 2023
Same HTTP timeout: |
EnricoMi
commented
Oct 27, 2023
Looks like a known unrelated issue, workaround here: https://github.com/kiegroup/kie-wb-common/pull/3416/files |
…h_snapshot workflow ### What changes were proposed in this pull request? This re-does #43538, which has [falsely been reverted](#43538 (comment)). Limit max memory for `mvn clean deploy` to `2g` when run in `publish_snapshot` Github workflow. ### Why are the changes needed? The host that runs the workflow has only 7G of memory, while the `release-build.sh` script sets the limit to 12g, causing the process to be killed (for branch `master`). ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? Not tested ### Was this patch authored or co-authored using generative AI tooling? No Closes#43555 from EnricoMi/publish-snapshot-mvn-xmx-2. Authored-by: Enrico Minack <github@enrico.minack.dev> Signed-off-by: yangjie01 <yangjie01@baidu.com>
I think a better alternative is to retry: https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#retryfaileddeploymentcount See #43559. |
HyukjinKwon
commented
Oct 27, 2023
Let's retry few times and see if it actually works first |
What changes were proposed in this pull request?
Limit max memory for
mvn clean deployto2gwhen run inpublish_snapshotGithub workflow.Why are the changes needed?
The host that runs the workflow has only 7G of memory, while the
release-build.shscript sets the limit to 12g, causing the process to be killed (for branchmaster).Does this PR introduce any user-facing change?
No
How was this patch tested?
Not tested
Was this patch authored or co-authored using generative AI tooling?
No