[erlang-questions] Experience with much memory

[Dániel Szoboszlay]

I would like to add to Richard's points that you may have to tune the
memory allocator settings of the Beam too above a few hundred GB-s. The
default values may lead to some fragmentation that is becoming significant
at this point, especially for long-term allocated memory (typically: ETS
tables). I would advise not to use address order first fit strategies for
example, but rather stick to the old default, best fit strategy. Using a
super carrier may be beneficial too if you expect to use a lot of memory.

Cheers,
Daniel

On Sat, 28 Sep 2019 at 17:07, Richard Carlsson <carlsson.richard@REDACTED>
wrote:

> We have been running Erlang/OTP on machines with up to 3 TB of RAM, for
> many years. The Beam VM has no problems with this; we have seen single
> Erlang processes within a Beam use a few hundred GB of temporary data and
> then deallocate it again, while the VMs can keep running for months on end.
> The problems at that scale typically show up in the OS kernel, and you may
> need to tune it to avoid long pauses in the OS memory management, and
> occasionally flush the page cache to defragment the RAM.
>
>         /Richard
>
>
> Den lör 28 sep. 2019 kl 16:03 skrev <buday.gergely@REDACTED>:
>
>> Hi there,
>>
>> are there experience reports on using Erlang/Elixir on systems with 200
>> GB of memory and more?
>>
>> If you have a first-hand account on that, please share it with me.
>>
>> My friends are doing that and said that only C++ was capable of handling
>> that.
>>
>> - Gergely
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190928/87523dc8/attachment.htm>