Overhead cost of using several Erlang VMs?

I’ve been learning about Elixir and it seems to be recommended that each project is packaged with its own Erlang VM. So if several projects are run on a single computer/VPS, this means that there would be several Erlang VMs running on that computer/VPS.

Are there any (recent) articles/posts/discussions about overhead cost (CPU/RAM) of using several Erlang VMs instead of single one?

I’m thinking of computer/VPS with 1-2 CPUs, so context switching will cause some CPU overhead,
and there is of course also some RAM overhead.

2 Likes

Hmm not sure I have heard that. Do you have a link regarding a VM per app? Maybe If the apps are entirely unrelated and this is a data isolation mechanism, sure.

Think many of us would agree the BEAM is more similar to an operating system than a language runtime…

Erlang has the concept of apps. A single Erlang cluster or VM can run probably thousands if not millions of ‘apps’ all effectively sharing system resources. Apps I believe are considered stateful in that BEAM processes are included. This state is what separates an Erlang app, from just module with functions…

For example, you could have n many phoenix endpoints in the same VM as long as they are bound to different OS ports.

I’m sure that’s not 100% accurate but is probably close enough…

Please people smarter than me correct, if I am wrong :stuck_out_tongue:

1 Like

If you have BEAM installed on your VPS you can run all your application with this local installation.

But that does not mean that those apps will run in the same runtime, just like if you run two elixir app on two terminal windows on your computer. They do not communicate by default.

So my bet is that that would not change CPU/RAM consumption.

That being said, if you do releases that package their own Erlang runtime, you can have different versions of it, your app is portable so you can change hosting easily once you are set up, etc.

1 Like

Per project not app. It’s said in Mix.Tasks.Release documentation, for example here but also elsewhere on this page:

:include_erts - … it indicates whether the Erlang Runtime System (ERTS), which includes the Erlang VM, should be included in the release. The default is true, which is also the recommended value. …

ok, I didn’t realize this, I thought runtime would’ve automatically been shared here.

In theory you can even make it so it will start separate Phoenix applications, but all will use the same Cowboy server, so from the developer point these will be separate, but all will be bound to the same listener (but you still need some way to distinguish between them).

1 Like

I’d think that having 2+ BEAM VMs live on the same physical server is going to demonstrate some lags and struggles in parallel workflows because each VM will try to utilize X processor cores (where X equals System.schedulers_online() which can be modified at startup). If each of the VMs is started with schedulers equal to all processor cores, and in loaded parallel workflows, then you’re going to see contention.

But then that applies to each and every other runtime out there.

If you want to split a single VPS or physical server to several BEAM VMs, you better divide the CPU cores fairly between them and utilize OS tools to allocate the right cores to the right BEAM VM.

…Or, as others said, just use a single BEAM VM for all your apps at once – assuming none of them is aggressively modifying other processes’ state or in general being a bad citizen.

4 Likes