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

[Ulf Wiger]

Joe, I believe that patch has been merged into the main. At least, gproc:goodbye() does exist there.

It should make some difference, since the server will have much less work to do for each DOWN message.

BR,
Ulf

On 9 Nov 2011, at 15:17, Joseph Norton wrote:

> 
> 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.
> 
> https://github.com/norton/gproc/commit/e2c4108c2ceae5d86ca78f9f1d5e5c6b45f7309a
> 
> 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
>> <ulf.wiger@REDACTED> 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
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> 

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com