Erlang Process Limits

[Raimo Niskanen]

Bruce Fitzsimons wrote:
> 
> Hello again,
> 
> Is the maximum number of processes on an Erlang node a hard limit, or is
> there the potential for this to be increased (beyond 32767)?
> 

It is a fairly hard limit since in the internal representation of a pid,
15 bits are used for the process table index on the node, and all other
bits are also used for essential things. This applies at least for the
Beam virtual machine up to release R8. We may change the internal
representation in future releases due to other reasons as well, but no
guarantees..., and in that case this limit might be raised, as well as
when a port to a 64 bit host processor comes.

> I am aware that requiring such a huge number may be an indicator that I
> should rethink my design, but it just maps cleanly to having 1 process for
> every call, with a parent process to manage them(2+ calls per real call).
> However this limits me to only 10000 simultaneous calls, which isn't that
> much for my application.
> 
> Is there any other way I can get around this limit without going to multiple
> nodes?
> 

I heard a customer that found that the scheduler became too sluggish
when they had a similar solution, so they changed their design to
increase performance, not because they had hit the number of processes
limit.

They found that not all calls were always particulary active, so during
idle states in the call lifetime they save the process state into an ets
table and stops the process. Their manager process then detects if
something happens on such a call, spawns a new process (processes are
cheap to spawn) and gives it the saved state.

/ Raimo Niskanen, Erlang/OTP, Ericsson UAB