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

[Ulf Wiger]

On 9 Nov 2011, at 15:00, Max Lapshin wrote:

> 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.

Actually, it can well be. Granted, the one time I managed to do this was when I had spawn-linked 100K processes from the shell, and then managed to crash the shell process through a typo (I was going to write length(processes()), but mistyped 'length'). The {undef, {erlang, lenth, [Pids]}} became a pretty large EXIT message, and the VM tried to create 100K copies of it in one atomic operation. It took 10 minutes before I regained use of my workstation...

I'll consider your use case, and try to come up with something that does scale without adding overhead to the normal case.

The other reason for disliking links in this case is that the server imposes an EXIT signal on the client that it basically has no reasonable reaction to. I think a logical extension of this is to rig gproc so that it always brings down the whole node if it crashes. Currently, the server can crash and recover, which is not a bad feature.

BR,
Ulf W

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