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

Chandru chandrashekhar.mullaparthi@REDACTED
Tue Nov 10 13:25:54 CET 2009


2009/11/10 Tony Rogvall <tony@REDACTED>

> Not yet.
>
> What kind of flavor do you have in mind?
>
> One proposal is to let sender crash when receiver in box is full.
>

A few strategies to choose from would be useful.

* Crash sender
* Crash receiver
* Discard message

cheers
Chandru

I would like to test a blocking version as well. This may sound like utterly
> crazy, but we already have the infamous busy_port ;-)
> Busy ports do block senders (mostly distribution stuff).
>
An other flavor is to drop the overflow message. This can however be done
> by catch (Pid ! Message) if the crash semantics is implemented.
>
> A suggestion from Patrik Winroth is to be able to set thresholds on
> resource limits,
> say in percent from max limit. When threshold is reached then a warning
> message
> is sent to a logger process.
>
> The max_memory limit currently control number of words! that can be
> allocated for heaps.
> This is the sum of sizes of all heaps for the process and it's
> "sub"-processes
> (spawned by process that had the limit set in the first place). It is
> implementation specific
> if the message queue and/or the messages them selfs are located on the
> process heap.
> In the case where messages are none shared and located on a separate heap
> fragments
> this should be accounted for.
>
> /Tony
>
>
>
>
>
> On 10 nov 2009, at 12.18, Chandru wrote:
>
>  2009/11/9 Tony Rogvall <tony@REDACTED>
>>
>>  Interesting discussion!
>>>
>>> I have been working on a resource system for Erlang for nearly two years
>>> now.
>>> I have a working (tm) prototype where you can set resource limits like
>>> max_processes/max_ports/max_memory/max_time/max_reductions ...
>>>
>>>
>> You don't happen to have a max_message_q_size option do you? Or does
>> max_memory implicitly enforce this?
>>
>> Chandru
>>
>
>


More information about the erlang-questions mailing list