-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Use less threads than we have cores on Jenkins, increase max heap #1032
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
? As @odersky correctly pointed out, the threads live in the process and share the same heap. Additionally, scalac runs on the same infrastructure with very same settings: 1 thread per cpu. I have a feeling that we are fighting symptoms, instead of trying to find the reason why memory consumption has spiked recently. Dotty used to be able to compile itself in 800mb heap in early December, without struggling with GCs. |
I agree that we should do that too, but in the meantime being able to have the tests pass would be great. |
0c0fbae
to
76cee24
Compare
I still cannot see diffs of commits in this PR. |
Yes, something is broken on github's side, I've seen this on other PRs too, I've sent a message to github support. |
Here's a trick that seems to work: you can add |
I propose we do not increase number of things that work differently on CI. WDYT? |
Using less threads should allow us to increase the maximum heap size without filling up the memory of the Jenkins instance
3e01551
to
bbb8904
Compare
But what happens when several PRs are tested at the same time on the same virtual machine? For example here https://scala-ci.typesafe.com/job/dotty-master-validate-partest/956/ and https://scala-ci.typesafe.com/job/dotty-master-validate-partest/957/ are run on |
OK, even dividing the number of threads used by 2 doesn't seem to be enough to avoid exhausting the RAM, so closing this. |
Using less threads should allow us to increase the maximum heap size
without filling up the memory of the Jenkins instance