Mnesia, table updates, and (UNIX) process bloat

[Scott Lystig Fritchie]

Greetings.  I'm a bit puzzled about R10B-9's behavior regarding
process size.  My platform is:

	Erlang R10B-9
	Linux EL3 + AMD Opteron (64-bit build), 4GB RAM
	Mnesia disc_copies tables
	Heavy update workload (I'm trying 2000 updates/sec, it's a
	    benchmark workload right now), where a fragmented Mnesia
	    table is updated with something approximately the same
	    size.

Odd behavior: The UNIX process size grows from a comfortable 2.4GB to
an uncomfortable 3.2-3.5GB in under 1 hour.  The 2,000 update/sec
benchmark slows down once the OS's VM paging starts, and then things
go rapidly downhill.

According to erlang:memory(), the 'total' and 'maximum' values only
grow about 100MB during the 1 hour.  But the UNIX process size grows
by roughly 1GB, sometimes a touch more.

Things I've tried:

    1. Adding "+r" to the "erl" command line
    2. Adding "+Mim true +MEas aobf" to the "erl" command line
    3. Switching from 'set' to 'ordered_set' tables
    4. Using an Erlang virtual machine with elib_malloc support

This smells like fragmentation of malloc's heap.  #1 is documented (I
forget where, at the moment) to avoid/slow fragmentation for some
kinds of ETS workloads.  Too bad it doesn't work for me.  Trying the
"address order best fit" scheme didn't help, nor #3 or #4.

Is there a silver bullet for this particular problem, or am I
sentenced to go spelunking with the "instrument" module and/or
valgrind's "memcheck" and/or ....

(I'm actually waiting for 16GB to arrive, but I'm wondering if this is
 going to eat 16GB eventually.)

-Scott

(*) Is the elib_malloc configure option broken?  Just using
"./configure --enable-elib-malloc" didn't seem to be enough, because
erlang:system_info(elib_malloc) would always return false.  I kludged
a Makefile (without RTFM'ing or the fine mailing list archives) to add
the necessary compiler "-D" bits, then added extra stuff to
erl_bif_info.c's "erts_system_version" string to help verify that I'd
defined the right CPP symbols.  Perhaps I used too much brute force?