httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: [users@httpd] apache over ServerLimit processes limit
Date Mon, 15 Feb 2010 15:05:55 GMT
On Mon, Feb 15, 2010 at 9:01 AM, Zdravko Spoljar
<> wrote:
> On Mon, 2010-02-15 at 07:29 -0500, Jeff Trawick wrote:
> <cut>
>> Anything that causes child processes to exit during steady state can
>> lead to extra child processes *when some requests take a relatively
>> long time to finish*.
> now, if i understand correctly "active child processes" != "child
> processes which are terminating" so relative long lived request hold
> additional childs alive, and apache spawns new one above ServerLimits to
> server new requests. And there is no directive which will limit number
> of apache processes in absolute sense?

Absolute control

Use this combination of directives:

MaxSpareThreads =MaxClients
MaxRequestsPerChild 0

Since graceful restart has the same effect -- telling a child process
to terminate even though the requests it is handling won't finish for
a long time -- you can't use graceful restart either.

Not absolute control but still work-able with a relatively small
number of extra child processes as long as individual requests don't

MaxSpareThreads not small enough that parent terminates child
processes except in rare circumstances (e.g., after a period of
abnormally high client connections)

MaxRequestsPerChild enabled, but only after a large number of requests
(e.g., 80000)

When you don't use absolute control, you'll need to monitor behavior
for a while to see if MaxSpareThreads or MaxRequestsPerChild needs to
be increased.

>                                   so only solution would be to use
> kernel mechanism for limiting number of processes for apache user.
> of course that can lead to "worst case" situation in which i will have
> up to 1 per child slow request finishing, and no "fast" traffic served
> because there are no available threads.
> right? :-)

(Solution above)

That's why worker allows these extra processes to be created.

>> Your very low value for MaxRequestsPerChild is the likely culprit.
>> You might have to increase MaxSpareThreads as well since that will
>> cause one or more child processes to begin termination when load
>> decreases by a moderate amount.
> that was in because i wanted relative short time of recycling processes,
> to avoid memleaks, but i get short of memory due long live requests :-(
> (that is relatively new problem, as php application works for over year)
> to summ:
> i should rise MaxRequestsPerChild to 5000 (or more),

I'd guess higher, but check watching the number of extra processes

>  and have slower
> rate of recycling processes?


>           and setup some way to kill off long live
> requests (maybe killed by firewall setup or by some mod_qos options).

investigate why they are long running; if because of client behavior
(very slow upload of large data), then firewall setup could help; but
often it is because some application logic is hung, and Apache will
wait forever for mod_php to return control

> also setup max number of processes in kernel

this should only be plan B just in case tuning of MaxSpareThreads and
MaxRequestsPerChild doesn't handle some rare condition

> (and max process RSS size)

one thread going over the limit will trash all other requests being
served by that process, right?

> to stabilize server (as apache cannot take care of itself).

because of the combination of threaded MPM, the need for aggressive
child process termination because of (presumably) an application
problem, and long-running requests

> i would rather have locked/crashed apache (which can be detected&fixed
> by cron job) than have unusable system due lack of memory (which i need
> to fix myself :)
> any way, thanks for precise point to my lack of understanding of
> implications of using MaxRequestsPerChild != 0.

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message