if you are able to determine how much core memory
is left, you may also be able to determine average apache
process size and variance. then, apache can determine
whether or not to start up any additional children. i'm not
sure how much processor time would be taken to determine
free core memory. might not be something worth doing on
every scoreboard cycle.
there is an additional bonus for determining child size mean
and variance. if it is noted that a process is growing exceptionally
large compared to other processes, it could be slated for death
based on its growth size and rate, rather than the number of
requests that it served.
Perrin Harkins wrote:
> On Wed, 17 Jan 2001, ___cliff rayman___ wrote:
> > i and others have written on the list before, that pushing apache
> > children into swap causes a rapid downward spiral in performance. I
> > don't think that MaxClients is the right way to limit the # of
> > children. i think MaxSpareCoreMemory would make more sense. You
> > could set this to 1K if your server was designated for Apache only, or
> > set it to a higher value if it were a multipurpose machine.
>
> I've thought about that too. The trick is, Apache would need to know
> things about your application to do that right. It would need to know how
> big your processes were likely to be and how big they could get before
> they die. Otherwise, it has no way of knowing whether or not there's
> enough room for another process.
>
> A combination of Apache::SizeLimit and a dynamically changing MaxClients
> could possibly accomplish this, but you wouldn't want to run it too close
> to the edge since you don't want to have to axe a process that's in the
> middle of doing something just because it got a little too big (i.e. no
> hard limits on per-process memory usage).
>
> You can't change MaxClients while the server is running, can you?
>
> - Perrin
--
___cliff [EMAIL PROTECTED]http://www.genwax.com/
