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
This may not be quite on topic. I wonder in the case of a dedicated
Apache/Mod_Perl server if it wouldn't be best to spawn up to a maximum
number of child procs that the server can handle at startup. Maximum
child procs calculated based on the amount of core memory minus amount
of real memory used by each proc (Stas Bekman mod_perl guide Performance
Tuning Section) with a cushion of free core memory to allow for some
process growth and handle misc. house keeping duties of the server. Then
use the Apache::GtopLimit module to prune child procs based on memory
size. If a child proc grows too large because of memory leaks for
example it is killed and a fresh proc spawned in its place. In this way
you always have as many procs available as your server can handle for
periods of high load. No wasted time spawning up to meet the load.
Jayme Frye
System Administrator
Inventive Comm.
