On Tue, 9 Jan 2001, Joshua Chamas wrote:

> Perrin Harkins wrote:
> > 
> > We added that in, but haven't contributed a patch back because our hack only
> > works on Linux.  It's actually pretty simple, since the data is already
> > there on Linux and you don't need to do any special tricks with remembering
> > the child init size.  If you think it would help, I'll try to get an okay to
> > release a patch for it.
> > 
> > This is definitely a better way to do it than by setting max size or min
> > shared size.  We had a dramatic improvement in process lifespan after
> > changing it.
> > 
> 
> I would like to see this, but how is it better than the min 
> shared size of Apache::GTopLimit

It's like this:
What you want to control is the maximum REAL memory that each process will
take.  That's not max size or min shared, it's max unshared.  If you try
to control this using the traditional max size and min shared settings,
processes often get killed too soon because it's hard to predict how much
of the max size will be shared in any given child.

Doing it this way also means you never have to adjust the settings when
you add in or remove modules.  The thing you care about - how much actual
RAM is used perprocess - is constant. 

> On the other hand, it seems nice to NOT HAVE to install libgtop for
> this feature, as Apache::SizeLimit is just a raw perl module.  

That's the main drawback to GTopLimit.

- Perrin

Reply via email to