[erlang-questions] Memory not freed after VM closed

[tom kelly]

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.