[Spread-users] Another way to leak (valgrind report)

[David Shaw]

On Tue, Aug 31, 2004 at 02:43:22PM -0400, Theo Schlossnagle wrote:
> On Aug 31, 2004, at 2:19 PM, David Shaw wrote:
> >I've attached a program that does that.  Running this program causes
> >spread's memory and fd usage to shoot upwards.  The fd count stops at
> >511, but by that time, spread has most of the physical ram on the box.
> >When the program finishes, spread's fd count eventually falls, but the
> >memory is not released.  I suppose this could be extraordinarily
> >agressive caching, but leak or cache, spread is ending up with far too
> >much memory.
> 
> Are you talking about the RSS?  It is unlikely for the RSS to ever 
> reduce.  UNIX heaps grow up.  So if I malloc 1GB, then malloc 1bytes, 
> then free the 1GB, my RSS won't shrink.

Well understood how sbrk interacts with malloc, and I'm talking about
both SIZE and RSS.  An excessive RSS may drop off as the OS pages it
out, but moving spread in and out of swap clobbers the machine.  I've
even seen a machine partition off from the rest of the spread segment
because it was spending too much time swapping to do any work.

Looking at this another way, I'd like to see spread protect itself
from overagressive clients.

I don't claim to have an easy answer in my back pocket, but many
projects that produce long running daemons have dealt with this
problem.  Partial solutions can be to allow specifying a limit to the
amount of memory that will be requested from the OS in the first
place, or to arrange memory in such a way that it *can* be given back,
or mmap /dev/zero or other less portable things, or any combination
thereof.

Currently, spread's memory usage seems to be whatever the high water
mark is since it was run.  This might be a philosophical point, but
this behavior means spread can be driven to the point where it causes
the OOM killer on Linux to start picking processes off.  I think
that's suboptimal.

David