[erlang-questions] gproc scalability, shared ets, links and using terminate/2

Joseph Norton <>
Wed Nov 9 15:17:02 CET 2011

I've been using a "goodbye" patch for the gproc application to help move some of the cleanup work to the client side and lessen the work of the centralized gproc server.


Not (quite) sure if this is helpful to your use case or not.

- Joe N.

On Nov 9, 2011, at 11:00 PM, Max Lapshin wrote:

> On Wed, Nov 9, 2011 at 1:06 PM, Ulf Wiger
> <> wrote:
>> It's true that link/1 has that advantage.
>> The disadvantage is that if the server crashes, and is linked to, say, 100K processes, the EXIT signal will be duplicated that many times, likely forcing an OOM crash.
> I understand. But I don't have anything to do, except hoping that
> server will not crash, because with monitor in my situation system
> gets frozen under normal load.
> And 100 K of messages is not a reason for OOM. Dumping these messages
> will be an OOM, error logger is the main reason to bring down VM.
> By the way, have you seen my previous claim about non-atomic process startup?
> Using supervisor  {error, {already_started,Pid}} feature is also not
> 100% unreliable because of race condition.
> _______________________________________________
> erlang-questions mailing list
> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list