[erlang-questions] Any guidance on tweaking allocator settings?

[Jordan Day]

Hi Metin, Fred, Lukas,


Thanks for the suggestions. I had previously consulted Erlang in Anger
about this issue (which lead me to Fred's great “down the rabbit hole” blog
post, and Lukas’ EUC presentation), but, as Lukas mentions, it doesn’t seem
to be an issue with fragmentation — in addition, I’ve tried to manually run
garbage collection on all the processes in the same manner as Metin
suggests, but it hasn’t helped much. Based on some more digging, it seems
the most likely culprit is probably just a combination of surprisingly
large allocations made while parsing the JSON, and bad program design on my
part. In a long-running process, I’m recursively calling into my function
for downloading a bunch of these JSON documents in what I *think* is a
tail-recursive manner, but I’m guessing I’m doing something that’s keeping
the memory from being freed during the recursion. When I instead spawn a
new process that fetches a single JSON document, parses it, and then dies,
I see memory (in top) spike by 100-200 mb, but settle back down fairly
quickly after the process terminates.


(sorry for the delayed response, my mail server at work seems to be
blocking me from sending replies?)

Thanks,

Jordan

On Apr 7, 2016, at 3:28 PM, Metin Akat <akat.metin@REDACTED> wrote:

Hello,


I recently had the same problem in quite identical situation. In my case it
was a load tester application that hammered onto a REST API. With several
thousand bots when hitting a method that returns ~1M JSON, the VM started
eating huge amounts of memory, until it crashed with out-of-memory
exception.


A very simple hack solved my problem (and that being a non-critical
application I don't really care bout the implications):


[garbage_collect(Pid) || Pid <- processes()].


I execute this every minute or so and my load tester never had the problem
again.


I imagine somehow it failed to trigger full-sweep GC ever and generational
GC never cleared the old parsed JSON terms allocated in the processes'
heap. But as it solved my problem, I never dug any deeper.


Regards,

Metin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160408/a33f4afc/attachment.htm>