[erlang-questions] Why Beam.smp crashes when memory is over?

Thomas Lindgren thomasl_erlang@REDACTED
Mon Nov 9 14:25:09 CET 2009

----- Original Message ----
> From: Andrew Thompson <andrew@REDACTED>
> ... it'd be nice to have an
> alternative in cases where nuking the VM and having to recover or simply
> discard a lot of state is unpleasant.
> In an ideal world I'd like to see an *optional* OOM behaviour similar to
> the following:
> On startup, the VM pre-allocates enough memory to be able to attempt OOM
> recovery without additional malloc calls. If and when an OOM condition
> is detected, freeze the VM, iterate the process list and simply
> exit(FatPid, oom) the process with the most memory allocated (obviously
> this strategy is full of holes, epecially with regard to off-heap
> binaries), but *sometimes* it's better than just blowing away the whole
> thing. Then, if the malloc fails again, revert to the current behaviour.

Another way of doing that might be to hand the decision to (a modified version of) the supervisor hierarchy (if any). The supervisor could get info on sibling priority (if any) and/or memory usage as part of the request perhaps. Restart up the supervisor hierarchy to suit. That might give more structure to the restarting.

Or you could do the OOM-killing in distributed erlang + unix instead. Run the buggy, memory-hungry stuff in a separate VM with a memory limit on the process, and manage the work from a "supervisor VM" using monitoring and rpc. Not quite as elegant, of course.



More information about the erlang-questions mailing list