apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Park <r...@cnet.com>
Subject Re: [PATCH] Free memory over a certain threshold back to the system
Date Wed, 06 Feb 2002 18:54:58 GMT
Ryan Bloom wrote:
> 
> > -----Original Message-----
> > From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> > Sent: Wednesday, February 06, 2002 8:59 AM
> > To: Sander Striker
> > Cc: dev@apr.apache.org
> > Subject: Re: [PATCH] Free memory over a certain threshold back to the
> > system
> >
> > On Wed, Feb 06, 2002 at 01:24:36PM +0100, Sander Striker wrote:
> > > Hi,
> > >
> > > The 'high free' patch.  I'm not sure we want this.
> > > It may hide pools abuse problems.
> >
> > Yeah, I agree we don't really want this.  If we run out of memory
> > with the normal pools, it means that the lifetimes are most likely
> > incorrect.
> >
> > But, perhaps this could be a #define with a debug option?  -- justin
> 
> We definitely don't want this IMHO.  If the pools are filling up, then
> either pools are the incorrect model for your app, or they aren't being
> cleared often enough.  I would much rather not have this as an option at
> all, because that just encourages people to use it.  :-)

I was under the impression this patch simply kept the free lists from growing
and staying excessively large, not 'filling up pools'.  There are some apps
which can and should use pools but which, during the course of their lifetime,
have periods of heavy usage and thus create an abnormally large number of
pools;
since these pools are never truly freed and hang around in the free_list
forever,
the process clings to this memory even if it's never needed again.

For instance, a process which accepts requests into an internal queue and
processes
them in seperate threads at a later time.  If the arrival rate (temporarily)
exceeds
the processing rate, the queues (and the associated pools) will grow
excessively
large.  Without this patch, even when all the pools are destroyed, the process
will
still hold onto that memory.

As someone who's got a process that is suffering from this behavior, I was
looking forward to this patch... perhaps it could be added as a compile time
option?

Is the pool model fundamentally flawed for this type of program?  I'd hate to
have
to strip all of APR out of my code; other than this, it's worked perfectly for
me.

Thanks,
Ron
-- 
Ronald K. Park, Jr.
ronp@cnet.com           CNET Networks / CNET.com / ZDNet / mySimon
 908.541.3738           The source for computers and technology.

Mime
View raw message