Minimize energy consumption for Erlang applications

Hi,

I have this Phoenix app online, it is private, a simple board game for my girlfriend and her friends.

I believe that the BEAM “keeps the CPU hot” or something like that, but we do not care about performance (generally we have a single game and maximum 4 players) and most of the time the app is idle. But we want to be able to play at any time, so the apps is always up.

The app is built with mix release and then started in a docker container (with docker-compose).

I would like to know all the ways I can lower the energy consumption of this app. I know there are erl flags (although I do not know how to set them in an Elixir release context), but maybe there is more.

Thank you.

2 Likes

Hello!

Here you can find more details about tweaking VM configurations: https://elixir-lang.org/getting-started/mix-otp/config-and-releases.html#operating-system-environment-configuration

Anyway, in rel/env.sh.eex, you need to set export ELIXIR_ERL_OPTIONS="+sbwt none". Here you can find more details about it: https://adoptingerlang.org/docs/production/kubernetes/#container-resources

I hope it helps!

3 Likes

Thank you, that is a very good start ! I was missing the term “busy wait” !

Would you say that with this flag the app is effectively idle ? (of course given I have no scheduled tasks, ecron, or stuff like that).

2 Likes

Have in mind that the busy wait is one of the things that actually makes the BEAM as responsive and lagless as it is. Without it, part of its value as a runtime is gone.

1 Like

It keeps its value in being a pleasant platform to develop for !

Could you elaborate though ? I woul believe that under heavy load the busy wait is unneeded because there is work to do, and when there are no requests, an incoming request would still be served very fast, no ?

The busy wait is needed so after the BEAM has been idle for a while and receives new work, it will respond immediately. If not for the busy wait, many Linux kernels spin down resources and I/O queues and this is why many systems lag when they suddenly receive new work again.

The BEAM dodges that mechanism through the busy wait. It makes sure the kernel doesn’t partially put it to sleep.

Sorry, I forgot the details and I am too lazy to find the source. But I think I got the general idea right.

2 Likes

For many use-cases a slight latency after a period of no load is an acceptable trade off for reduce power usage, such as on embedded devices. It sounds like @lud doesn’t need that kind of performance here, the server will warm up when the players join the game, and board games rarely have extreme performance constraints.

It’s a only a very slight latency- the same as you’d have in most other languages where busy looping is rare.

4 Likes

Sure, I was just informing him about the tradeoffs.

Indeed, as @lpil said performance has little importance here, but any information about BEAM mechanisms is good to know.

Thank you both.

1 Like