[erlang-questions] Max open files and erlang memory

[Jayson Vantuyl]

I'm unclear on the design decisions that went into this, but having  
done some embedded work myself, these structures are almost always  
preallocated.  The prevailing wisdom is that embedded systems must be  
able to make acceptable progress in the face of memory exhaustion.   
Since Erlang is designed to be highly fault-tolerant, I would imagine  
that this is the primary reason that the port-table (and, indeed, the  
atom table as well) are pre-allocated.  In the embedded systems world,  
how something fails is often more important than how it succeeds.

As an example of the behavior to be avoided, look no further than  
loading code.  If the code-server can't load a file due to memory  
exhaustion, it may be unable to upgrade the system to fix the bug  
causing the memory exhaustion.  Basically, no new code can be loaded,  
no configuration files read, etc.  All because we don't have the  
memory to allocate "on-demand".  This causes memory exhaustion to  
cause cascading failures in any system that didn't set aside some  
memory.  This is exceptionally bad, because (under Erlang) it's quite  
likely that whatever is consuming memory will get killed and the  
memory pressure will go away.  If we wedge the system in the meantime,  
that's just no good.

 From a failure perspective, this may increase the frequency of  
failures by creating artificial exhaustion of a resource (namely  
ports); but this is worthwhile because it makes those failures less  
severe (and more deterministic) by decoupling memory exhaustion  
failures from port allocation failures.  Designing away "cascading  
failures" such as this creates a big design win--especially when you  
may end up building an embedded system where memory exhaustion must be  
tolerable (and is more often transient).

On Aug 25, 2009, at 4:57 AM, Vincent de Phily wrote:

> On Monday 24 August 2009 23:09:25 Per Hedeland wrote:
>> The runtime creates an array of port structures (100+ bytes IIRC)  
>> sized
>> as the next power of two at or above your "max-open-files" (a.k.a.
>> sysconf(_SC_OPEN_MAX)) - this has been true since at least R10,  
>> probably
>> much earlier. I.e. the following from erlang(3) is only correct
>> regarding the default if you have a "max-open-files" of 1024 (or  
>> less) -
>> which happens to be the default on Linux I believe.
>>
>>      The maximum number of ports that can be open at the  same  time
>>      is  1024  by  default,  but can be configured by the environment
>>      variable ERL_MAX_PORTS.
>>
>> The ERL_MAX_PORTS part *is* correct though - and you can use this to
>> *reduce* the size of that port array. Oh, there is actually an upper
>> limit - 2^28 as far as I can see. And 1024 is the *lower* limit. See
>> init_io() in erts/emulator/beam/io.c.
>
> Thanks a lot for the pointers. I'll use ERL_MAX_PORTS to tweak  
> memory usage on
> a per-instance basis.
>
> I still wish the memory wasn't allocated untill needed, but I won't  
> try to
> argue against beam developpers regarding performance-related design
> decisions :)
>
>
> -- 
> Vincent de Phily
> Mobile Devices
> +33 (0) 666 301 306
> +33 (0) 142 119 325
>
> Warning
> This message (and any associated files) is intended only for the use  
> of its
> intended recipient and may contain information that is confidential,  
> subject
> to copyright or constitutes a trade secret. If you are not the  
> intended
> recipient you are hereby notified that any dissemination, copying or
> distribution of this message, or files associated with this message,  
> is
> strictly prohibited. If you have received this message in error,  
> please
> notify us immediately by replying to the message and deleting it  
> from your
> computer. Any views or opinions presented are solely those of the  
> author
> vincent.dephily@REDACTED and do not necessarily represent  
> those of
> the
> company. Although the company has taken reasonable precautions to  
> ensure no
> viruses are present in this email, the company cannot accept  
> responsibility
> for any loss or damage arising from the use of this email or  
> attachments.
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>



-- 
Jayson Vantuyl
kagato@REDACTED