Sage10 build with bud is painfully slow on t3.small AWS EC2 server

Hi I’m having trouble to get yarn build to run smoothly on a AWS EC2 t3.small server.

I understand that t3.small is relatively small server but it used to build fine but now it won’t even successfully build.

Over last two months it went from “taking 30second to build” to “taking more than 30 minutes to build”. And now it simply dies after a few minutes with “error Command failed with signal “SIGKILL””.

From what I can tell when I try to run yarn build it bring the cpu load to 100%. There is still plenty o cpu credit left so defintely not caused by that. Why is bud build this cpu hungry?

Hm, the build step is usually performed on a workstation or dedicated build machine/CI server/instance, not on the production system.
After the build the build artifacts are transferred to production and just served there as static files (of course, there may be still some dynamic look-ups, e.g. for hashes and initially rendering the Blade-PHP templates to cache (warm up) ‒ but normally those are very cheap and fast).

Is there a particular reason for why you are building the theme on an AWS instance instead of e.g. your workstation, a build server or a CI server/instance? This would be a faster and affordable alternative, especially as the build environments need to be ephemeral only.

Hi thanks for the reploy @strarsis.

Definitely prefer not to build on workstation because we use git for deployment, building it on workstation would require us to commit compiled assets to git which we prefer not to do.

For build server do you have any recommendation on how we can go about it ? (we use EC2 instances and repo is hosted on Github)

As you probably don’t self host, a hosted CI solution would be better suited IMHO.
GitHub itself has GitHub Actions which is free to some degree (depending on usage) (About billing for GitHub Actions - GitHub Docs).
Those build environments are only needed for the duration of the build, and then torn down again.

If you (still) want to find the underlying the issue in the AWS instance: You can profile the build process and find out the bottleneck or resource shortage: Easy profiling for Node.js Applications | Node.js

1 Like

Can you provide us with a git repo that contains a minimal reproducible example?

Hey @ben thanks we decided to up the server size that sidestepped this issue for now.

Thanks @strarsis we decided to up the server size that sidestepped this issue for now; but I should look into a build solution that’s outside of the webhost.