[erlang-questions] Erlang Memory Question

[Michael Truog]

If garbage collection isn't happening quick enough, you can generate the problematic data within a temporary process to make the temporary process' death trigger garbage collection naturally.  Doing that is a natural way to approach it.  The tuning is something additional that is optional.  I have a module I had used in the past to be as harsh as possible to the garbage collector (i.e., force it as much as possible) here https://gist.github.com/okeuday/dee991d580eeb00cd02c but I don't think it is necessary with a decent architecture in-place (being that harsh shouldn't be necessary).  If you need to check the memory consumption of your processes http://www.erlang.org/doc/man/instrument.html is very helpful.

On 09/22/2014 07:24 PM, Eranga Udesh wrote:
> Thanks for the information received so far.
>
> Wouldn't it be good for Erlang to have a single object garbage collection function/bif? For example, when I no longer require a large object, I force to garbage collect it, without making a full sweep?
>
> As mentioned in the document, a full sweep may degrade the performance.
>
> - Eranga
>
> On Tue, Sep 23, 2014 at 12:10 AM, Björn-Egil Dahlberg <wallentin.dahlberg@REDACTED <mailto:wallentin.dahlberg@REDACTED>> wrote:
>
>     It should suffice by running an erlang:garbage_collect/0 directly after extracting some parts of the structure:
>
>     function1() ->
>
>         X1 = ... fetch a large object ....
>
>         ... some processing...
>
>         X2 = ... extract a part of X1 ...
>         erlang:garbage_collect(),
>         ... long running job....
>
>
>     As long as the object of X1 is not referenced by the process after the explicit call to the gc, you're fine.
>     Note also, an explicit call to garbage_collect/0 will always to a 'fullsweep'.
>
>     Ofc, as Jesper mentioned, the it's probably preferable not to fetch the whole object if possible.
>
>     // Björn-Egil
>
>
>     2014-09-22 19:56 GMT+02:00 Jesper Louis Andersen <jesper.louis.andersen@REDACTED <mailto:jesper.louis.andersen@REDACTED>>:
>
>         In general: No it won't. GC will trigger once the process has allocated enough data. If your processing is allocating enough data, this will quickly happen and you don't have to worry. If not, you may have to gently persuade the process to do so. There are several ways:
>
>         * Set fullsweep_after on the process with a low value (0) and run erlang:garbage_collect()
>         * Go through a hibernation with an immediate wakeup (feels ugly to me)
>         * Handle fetching and extraction in a separate process and send the extracted part 'x' back as a message. This will free up memory almost immediately for other processes to use (simple and elegant)
>         * Don't fetch the large object in the first place, but make it possible to ask for an extraction only. Or stream data a bit at a time and handle the stream in chunks rather than everything at once.
>
>
>         On Mon, Sep 22, 2014 at 4:11 PM, Eranga Udesh <eranga.erl@REDACTED <mailto:eranga.erl@REDACTED>> wrote:
>
>             Hi,
>
>             I'm trying to optimize my memory consumption in Erlang VM and to garbage collect as soon as possible.
>
>             Let's say I have a large object, "X", After some processing, I only need to work on small part of X, called "x".
>
>             Can someone advice me if below process flow will put the large object X in to garbage collection, while waiting for the long running job to continue?
>
>             function1() ->
>
>                 X = ... fetch a large object....
>
>                 ... some processing...
>
>                 x = ... extract a part of X...
>                 ... long running job....
>
>
>             If it's not putting X into garbage collection, does below change do that?
>
>             function1() ->
>
>                 X = ... fetch a large object....
>
>                 ... some processing...
>
>                 x = ... extract a part of X...
>                 function2(x).
>
>             function2(x) ->
>
>                 ... long running job...
>
>
>             Tks,
>             - Eranga
>
>             _______________________________________________
>             erlang-questions mailing list
>             erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>             http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
>         -- 
>         J.
>
>         _______________________________________________
>         erlang-questions mailing list
>         erlang-questions@REDACTED <mailto: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/20140922/982e8225/attachment.htm>