[erlang-questions] Possibly memory leak in R17
Fri Apr 18 14:33:53 CEST 2014
Try recon (https://github.com/ferd/recon), more specifically, the
recon_alloc module (http://ferd.github.io/recon/recon_alloc.html)
1. Check `recon_alloc:memory(usage)' -- this is equivalent to the same
function being called with `used' and `allocated' and dividing them.
This will tell you if the memory that the VM knows about matches what
the OS reports
If the `allocated' value for `recon_alloc:memory(usage)' matches what
the OS sees, then your leak is at least not likely to be related to
bad driver or ERTS code (it's been put inside the util_allocs they
needed to put it in), which at least restricts the possible avenues.
2. Call `recon_alloc:memory(allocated_types)' to see which type of
util allocator (eheap, binary, ets, etc.) is allocating the most
memory. See if one looks like an obvious culprit when you compare the
results with `erlang:memory()'.
3. Call `recon_alloc:fragmentation(current)' to see a list of under-used
util allocators. The returned results are sorted by a weight system
that is somewhat likely to return the most fragmented allocators
first, based on their percentage of use and the total size of the
carriers, for both sbcs and mbcs.
If you see very low ratios, see if they differ when calling
`recon_alloc:fragmentation(max)', which should show what the usage
patterns were like under your max memory load. If there is a big
difference, you may be having issues with memory fragmentation, and
tweaking your options may help
Hopefully that will help.
: `recon:set_unit(byte | kilobyte | megabyte | gigabyte)' will let
you change the unit reported by all functions of this module.
: These options are described at http://erlang.org/doc/man/erts_alloc.html
And I tried to make a visual explanation as part of this blog post:
On 04/18, Max Lapshin wrote:
> I've released next version of our streaming server erlyvideo on R17 and we
> see something, perhaps memory leak on production.
> (flussonic@REDACTED)4> erlang:memory(total).
> 2GB is a very moderate consumption, so no problem here.
> top shows that beam.smp is using 6.6g of RES memory.
> No custom-made drivers are used on this machine and only one nif is used.
> Are there any ways to collect more info?
> erlang-questions mailing list
More information about the erlang-questions