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

[Ulf Wiger]

Richard O'Keefe wrote:
> 

> I am not denying the *need* for limits.  (Anyone else remember "engines"
> in Scheme?)  I've had enough functions in enough languages go into
> infinite recursion that I can see the point of stopping them.
> 
> However, Ulf Wiger has not addressed these points:
> 
>  - if the tagging scheme is changed (and it has in the past),
>    memory requirements may change.
 > ...

Perhaps I'm colored by having worked on systems where every
product release was preceded with months of relatively
thorough testing, where monitoring memory usage during
important operating conditions was routine.

We would also tune the system by setting process heap size
for important processes in order to minimize garbage
collection. This obviously needed to be reviewed anytime
something changed substantially.

Another type of tuning is to limit the number of jobs of
a given type that can execute concurrently. Again, this is
dependent on the actual memory use of a process.
When pushing high-throughput messaging systems to their
limits, these activities tend to become necessary, and they
have to be repeated for each significant revision of the
software.

A near-trivial case where memory requirements indeed will
change is if one switches from 32-bit to 64-bit Erlang.
This can cause memory usage in many Erlang applications to
roughly double (depending on how much binaries are used).


> At any rate, I am not saying that space limits are an essentially
> bad idea, or that some means of providing such limits shouldn't be
> added to Erlang.  What I'm saying is that
>   - GETTING the limits right is never going to be easy
>   - KEEPING the limits right is never going to be easy
>   - EXPLAINING how to determine appropriate limits in fairly simple
>     terms is going to be a very important part of Erlang documentation
>   - CHECKING the limits, perhaps with some sort of load testing tools,
>     is going to become an important part of development and maintenance.

Agreed.

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com