[erlang-questions] How to tune erlang memory allocator to use 25 GB of ram and stop munmaping it?

[Peer Stritzinger]

On 2013-08-26 13:52:44 +0000, Björn-Egil Dahlberg said:

> As of R16 MBCs are allocated in fixed sizes (power of 2) and each size 
> has its own freelist. The region sizes for new MBCs grows according to 
> allocating pressure. SBCs are different. The freelist for SBCs is a 
> circular list (but conceptually a stack). Free SBCs are pushed to the 
> freelist (you will usually use the same size very soon, hence you want 
> it first). When allocing a SBC the segment allocator will search the 
> freelist for a segment with suitable size and if none is found it will 
> then map a new segment. The freelist is emptied at the end of the list 
> and these slots are unmapped periodically as well as when cache 
> clearing occurs, i.e. nearing end of memory. 

Ok, so no need to add extra fixed size freelists as a malloc/free 
wrapper if this is already done internally.

> The memory allocator is a fairly complex piece of machinery. It 
> balances speed, scalability and fragmentation and does this on multiple 
> levels. You want to get most of your allocations in the MBCs but for 
> large heaps and large binaries this is of course impossible. 
> 
> There is no real downside here but memory tuning can be highly 
> application dependent and there is no real "one size fits all". My 
> suggestion is to tune your system and measure.

Yeah, will add logging + metrics to the OS malloc/free and tune 
according to these.

> I do agree that there should be an option to pre-map/allocate the 
> entire space of allocatable memory for the runtime system. It would be 
> better for the segment allocator to handle the entire region itself 
> rather the to rely on the operating system. We will probably add an 
> option for it sometime but I don't know when, maybe for R17 but 
> probably later.

This would be a *very* helpful feature for embedded systems.  All the 
non Erlang stuff is fairly static and if ERTS could grab the rest 
afterwards and manage it itself this would give the best results and 
even without tuning.  Probably Erlangs memory can be handled even 
better when it knows right from the start: this is your memory and 
thats it.

Cheers
-- Peer


> 
> // Björn-Egil, still on vacation.
> 
> 
> 2013/8/26 Peer Stritzinger <peerst@REDACTED>
> On 2013-08-20 15:04:41 +0000, Lukas Larsson said:
> 
> Hello Peer,
> 
> On Tue, Aug 20, 2013 at 12:43 PM, Peer Stritzinger <peerst@REDACTED> wrote:
> My favorite behaviour would be for Erlang to either grab all memory 
> available or at least a fixed amount on startup and hold on to it 
> forever.  Hopefully without fragmenting it too much (I know in case of 
> binary heaps that this isn't possible which is a bit disturbing to me).
> 
> Can this be achieved by the current ERTS with some parameter settings?
> 
> You could request that the main mbc (+M<S>mmbcs) should be preallocated 
> to a certain size, and this would kind of get the effect you are 
> looking for. However this is controlled on a per allocator level, so 
> you have to figure out which type of memory it is that you are using. 
> It also will only work for any mbcs allocated, all sbcs will still be 
> allocated using mmap/malloc. If you want to force only mbcs you could 
> up the sbct to very big, just remember to up lmbcs as well so that can 
> fit all of your sbcs into the mbc.
> 
> I do not recommend doing this, but it is possible.
> 
> I see, probably time is better to just optimize the system malloc for 
> erlangs use cases.
> 
> 
> Which direction should I look if I want to add behaviour like this?
> 
> BTW:  next best thing is to malloc/free allways same size tiles this 
> would avoid outer fragmentation and could be sped up relatively easily.
> 
> The emulator already tries to do this to the best of its abilities. 
> mbcs mmap requests grow depending on how you setup lmbcs, smbcs and 
> mbcgs. sys_alloc (i.e. malloc) calls are always multiples of +Muycs.
> 
> Having allocs multiples of a fixed number helps against small scale 
> fragmentation, on the larger scale if there is no memory mapping there 
> is still possibility of fragmentation with this scheme.
> 
> 
> You could set smbcs to the same as lmbcs if you want to, this makes it 
> so that all mbcs have that same size.
> 
> I'l try this out, any downsides of doing this?
> 
> This would remove all fragmentation issues and malloc/free could be 
> sped up by just having a special free list for these fixed size tiles.
> 
> Cheers
> -- Peer
> 
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions