Fix busywait on docker-entrypoint script #832

Merged

floatingghost merged 1 commit from cevado/akkoma:fix-busy-wait-docker-entrypoint into develop

2024-09-24 23:52:08 +00:00

cevado commented

2024-08-20 22:33:50 +00:00

Contributor

rel/vm.args.eex are only applied to releases.
this one adds the flags to disable busywait for BEAM in the default entrypoint of the Dockerfile.

more info on busywait and docker relation can be read here
https://stressgrid.com/blog/beam_cpu_usage/

rel/vm.args.eex are only applied to releases. this one adds the flags to disable busywait for BEAM in the default entrypoint of the Dockerfile. more info on busywait and docker relation can be read here https://stressgrid.com/blog/beam_cpu_usage/

cevado added 1 commit 2024-08-20 22:33:51 +00:00

Fix busywait on docker-entrypoint script

ci/woodpecker/pr/build-amd64 Pipeline is pending

Details

ci/woodpecker/pr/build-arm64 Pipeline is pending

Details

ci/woodpecker/pr/docs Pipeline is pending

Details

ci/woodpecker/pr/lint Pipeline is pending

Details

ci/woodpecker/pr/test Pipeline is pending

Details

b312edac4c

cevado commented

2024-08-20 22:39:39 +00:00

Author

Contributor

some other improvements that could be done:

change the dockerfile to build a release, this could be done with a Dockerfile using stages, this way you only need to push to your server the stage with the release.
make elixir, erlang and alpine versions configurable by envvar, this way when building the image for new versions no changes would be needed in the dockerfile.

i can open an issue for that if it's something desired.

some other improvements that could be done: - change the dockerfile to build a release, this could be done with a Dockerfile using stages, this way you only need to push to your server the stage with the release. - make elixir, erlang and alpine versions configurable by envvar, this way when building the image for new versions no changes would be needed in the dockerfile. i can open an issue for that if it's something desired.

Oneric commented

2024-08-21 00:01:38 +00:00

Member

Thanks, preconfiguring this for Docker like for OTP releases should be good although as done here it will be less convenient to disable if desired.

However, a Docker overhaul is already in the works in #803 letting Docker containers use OTP releases internally

Thanks, preconfiguring this for Docker like for OTP releases should be good although as done here it will be less convenient to disable if desired. However, a Docker overhaul is already in the works in #803 letting Docker containers use OTP releases internally

cevado commented

2024-08-21 11:59:47 +00:00

Author

Contributor

preconfiguring this for Docker like for OTP releases should be good although as done here it will be less convenient to disable if desired.

that's the thing, this configuration just makes sense when running on docker or a shared machine. i don't see a reason why someone running that on docker would like a container holding the cpu busy when it's not using it.

I can change it to check a flag for choosing between both ways to start, but particularly i don't think it makes that much sense.

> preconfiguring this for Docker like for OTP releases should be good although as done here it will be less convenient to disable if desired. that's the thing, this configuration just makes sense when running on docker or a shared machine. i don't see a reason why someone running that on docker would like a container holding the cpu busy when it's not using it. I can change it to check a flag for choosing between both ways to start, but particularly i don't think it makes that much sense.