[erlang-questions] Memory not freed after VM closed

[Patrik Nyblom]

Hi!

My guess is that this has nothing to do with Erlang, it's just disk 
cache. You'll get the memory back when you need it.
See for example:
http://www.linuxatemyram.com/
for more details.

Cheers,
Patrik

On 08/16/2013 11:27 AM, tom kelly wrote:
> Hi list,
>
> We're confused here by a memory usage problem that we're seeing. We're
> writing a lot of data chunks to disk and are seeing higher than
> expected memory usage, that lingers even after the Erlang VM has
> stopped.
>
> I've trimmed it down to a simple minimal testcase, just open an erlang
> shell, open a dets file and write some data chunks to the dets file.
> In my test I write 45000 4KB chunks for 180MB of data (I get the data
> from crypto:rand_bytes/1 but the source doesn't affect the behaviour)
> and afterwards erlang:memory/0 shows that we're using ~12MB of RAM
> that agrees with what both "top" & "ps aux" accounts for in the beam
> process.
>
> What's weird is that top also reports (in the total memory used
> figure) 300MB of RAM has been used up while filling the dets table but
> does not account for it under any process (the amount of extra RAM
> consumed always seems to be between 1.5 & 2 times the amount of data
> written to disk).
>
> I can delete all the data from the dets file and close it with no
> effect on the inconsistent top output. I can then shutdown the Erlang
> VM, with no effect on the inconsistent top output.
>
> While monitoring top I can see that the RAM is only freed after I
> delete the dets/bitcask file/s from disk, the total RAM accounted for
> by "ps aux" does not change with this step. Or, if I re-run the test
> it gets freed up when the dets table is re-opened.
>
> I'm seeing this behavior here with R16B:
> Erlang R16B (erts-5.10.1) [source] [64-bit] [async-threads:10] [hipe]
> [kernel-poll:false]
>
> And my OS:
> uname -a
> Linux host 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux
>
> But I also see it on R14B02:
> Erlang R14B02 (erts-5.8.3) [source] [64-bit] [rq:1] [async-threads:0]
> [hipe] [kernel-poll:false]
> Linux host 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012 x86_64 GNU/Linux
>
> It seems like way too big an issue not to have been noticed before
> now, can anyone else reproduce it?
>
> We're easily confused here at the best of times ;-) so if anyone can
> shed any light on what's holding onto this RAM it'd be much
> appreciated! Ideally we'd like to get this 300MB freed up straight
> away after writing everything to disk.
>
> //TTom.
> _______________________________________________
> 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/20130816/67735223/attachment.htm>