-
Notifications
You must be signed in to change notification settings - Fork 87
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
Document how to use BuildKit options to reduce resources consumption #125
Comments
Can you please try the following solution?
This solution seems to work for me, in the sense that I see only two layers built simultaneously. If this works for you as well, then I think that it should be the recommended approach, and we should add these instructions to the troubleshooting docs. |
Yes @regisb, it did what is expected, I can it only does two thing at a time. |
I second @regisb's proposal. A nice and simple way to reduce resource usage. |
[Update] I had to change it to use one worker, when testing on Mac M2 mini with 8GB of RAM: while building, running
CPU would fluctate between 100-200%, I/O aroud 800MB, PIDs can reach up to to 60. That when using one worker. The crash error I would get otherwise, npm killed something. To use one worker, I had to update the file pointed above and then running this command:
|
Also after the build is done
Why is it still running, it make sense that CPU is 0% because build is done, however it still consumes a lot of RAM. I am not sure what magic does buildx/builder do, but I had to stop it The builder would initially be inactive |
Running with just two workers exceeds your 8GB of RAM??? This would mean that building a single MFE requires 4GB of RAM? If this is true then we really need to rename MFE to macrofrontends.
Buildx is actually a process that runs inside a docker container -- as implied by the |
No objections from me. ;P |
I changed the title of the issue to reflect the decision proposed in my earlier comment. |
For those that end up at this PR trying to solve the following error when running
The answer appears to be the parallelism situation described here. Documentation on how to fix it is now here: https://github.com/overhangio/tutor-mfe?tab=readme-ov-file#mfe-development Scroll down to the end of the "MFE Development" section, right before "Uninstall", and you'll find some steps to reduce the max-parallelism, which means the launch process will try to do way fewer things at once and, hopefully, succeed:
(That file can be created anywhere, see the link for more details) |
Context
By palm it's expected that tutor/tutor-mfe would require BuildKit to be enabled by docker which is the case by default for docker since 23 version that is BuildKit is the default builder1.
Buildkit adds extra features to tutor/tutor-mfe, mainly cache related, however one of it's main feature.
Would consume a lot of resources in case of tutor-mfe, given it would run
npm install
andnpm run build
concurrently for the X MFEs that are enabled by tutor-mfe, this can lead to errors related to network for former and the high resources consumption for the latter.Also another concern about this is that consider the case of which the same machine that is used to deploy an Open edX instance is used for building, it's would be quite risky a low resources machine to run build the image while also having tutor containers running. i.e. in case system crash, it would the affect the availability of the service.
Possible solution:
Note: Those are not exclusive of each others.
Related issue/concern:
Also in Development mode, it has been observed that typically a developer would need to work on a specific MFE, however tutor dev would by default run all MFEs in development mode, i.e.
npm run start
X times of the enabled MFEs, while is totally different issue, it's probably related.Possible outcomes at least before palm release
Footnotes
https://docs.docker.com/build/buildkit/#overview ↩ ↩2
Docs https://docs.docker.com/build/buildkit/configure/#max-parallelism ↩
Slack thread https://openedx.slack.com/archives/CGE253B7V/p1684170597489729 ↩
The text was updated successfully, but these errors were encountered: