search

monero-project / monero

Monero: the secure, private, untraceable cryptocurrency
https://getmonero.org
Other
9.05k stars 3.12k forks source link

CI: -j4 with lin/win runners #9510

Open plowsof opened 1 month ago

plowsof commented 1 month ago

https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories

not yet able to confirm windows builds . ( i think unrelated but im having issues with gitian for lin/win using master on my own fork)

jeffro256 commented 1 month ago

What kind of issue? Adding threads probably won't make the build work better

plowsof commented 1 month ago

What kind of issue? Adding threads probably won't make the build work better

as per selstas comment, i thought the runners where unstable (even with 16GB of ram) to explain why we use 2.. 3 threads, but they previously had only 8GB of ram so it makes sense now.

The gitian issues i see is unrelated to resources, i am trying to build master,selsta is aware that its not building as it hasn't been attempted for over a year. for reference: gitian master branch run

iamamyth commented 1 month ago

Out of curiosity, does anyone know the approximate RAM requirement (i.e. a fairly close upper bound)? If so, I might be willing to add a follow-on PR to auto-set the number of runners, which, aside from future auto-scaling, would serve to document the rationale for the computation.

plowsof commented 1 month ago

@iamamyth win/linux runners have 16GB of ram with 14GB SSD of storage each. the full runner list specs can be found in the link in the OP. *sorry, the upper bound is 2GB per thread i think?

iamamyth commented 1 month ago

Looking through the history described in this PR, it seems 8GB didn't suffice for 4 threads, but worked for 3 threads, and 16GB works for 4 threads, so perhaps 2.75 GB/thread would be appropriate (leaves a bit of breathing room vs the 2 2/3 GB strict bound).

iamamyth commented 1 month ago

I got auto-configuration of the runner count working on my fork and can confirm the changes here match my above formula (at least 2.75 GiB and one core per worker).