<div><div dir="auto">Thanks Fred. Your recon library helped me a lot with additional tools like observer_cli (which wraps most of recon calls in a nice console GUI):</div></div><div dir="auto"><div><a href="https://github.com/zhongwencool/observer_cli/blob/master/README.md">https://github.com/zhongwencool/observer_cli/blob/master/README.md</a></div><br></div><div dir="auto">I’ve most of these information in my possession as I said to share in private. I will try the other ideas and report back.</div><div dir="auto"><br></div><div dir="auto">/Frank</div><div dir="auto"><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/31, Frank Muller wrote:<br>
>After adding a new feature to my app (running non-stop for 5 years), it<br>
>started leaking memory in staging.<br>
><br>
>Obviously, I’m suspecting this new feature. Command top shows RES going<br>
>from 410m (during startup) to 6.2g in less than 12h.<br>
><br>
>For stupid security reasons, it will take me weeks to be allowed to share<br>
>collected statistics (from recon, entop) here, but I can share them in<br>
>private if someone is willing to help.<br>
><br>
<br>
I'd recommend checking things like:<br>
<br>
- recon_alloc:memory(usage) and see if the ratio is high or very low; <br>
  this can point towards memory fragmentation if the ratio is low.<br>
- in case there is fragmentation (or something that looks like it) <br>
  recon_alloc:fragmentation(current) will return lists of all the <br>
  various allocators and types, which should help point towards which <br>
  type of memory is causing issues<br>
- if usage seems high, see recon_alloc:memory(allocated_types) to see if <br>
  there's any allocator that's higher than others; ETS, binary, or eheap <br>
  will tend to point towards an ETS table, a refc binary leak, or some <br>
  process gathering lots of memory<br>
<br>
Based on this it might be possible to then orient towards other avenues <br>
without you having to share any numbers.<br>
<br>
Quick checks if it's binary memory is to call recon:bin_leak(10), which <br>
will probe all processes for their binary memory usage, run a GC on all <br>
of them, then run a probe again, and give you those that have the <br>
largest gap. This can point to processes that had the most dead memory.<br>
<br>
There's an undocumented 'binary_memory' option that recon:info, <br>
recon:proc_count, and recon:proc_window all support -- it's undocumented <br>
because it might be expensive and not always safe to run -- that you can <br>
use to find which processes are holding the most binary memory; after a <br>
call to bin_leak, this can let you know about biggest users.<br>
<br>
You can also use proc_count with:<br>
- message_queue_len for large mailboxes<br>
- memory for eheap usage<br>
<br>
You can use the same values with proc_window to see who is currently <br>
allocating the most.<br>
<br>
If ETS is taking a lot of place, calling ets:i() can show a bunch of <br>
tables with content; you might have a runaway cache table or something <br>
like that.<br>
<br>
Regards,<br>
Fred.<br>
</blockquote></div></div>