httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: accept mutex failure causes fork bomb
Date Tue, 15 Sep 2009 14:33:21 GMT
On Mon, Sep 14, 2009 at 4:27 PM, Greg Ames <ames.greg@gmail.com> wrote:

> * Should we yank the squatting logic?  I think it is doing us more harm
> than good.  IIRC it was put in to make the server respond faster when the
> workload is spikey.


It finally occurred to me what you meant by spikey: triggering
MaxSpareThreads (duh).

The other conditions with squatting are graceful restart and
MaxRequestsPerChild.


>   A more robust solution may be to set Min and MaxSpareThreads farther
> apart and allow ServerLimit to be enforced unconditionally.



and not use graceful restart or MaxRequestsPerChild and hope you don't get
any child-fatal errors while long-running requests are being handled

and/or set ServerLimit "enough higher" than MaxClients / ThreadsPerChild to
allow ServerLimit to be enforced unconditionally even while some number of
processes hang around while a few dangling requests complete

--/--

slightly?-over-generalization:

The real problem is that processes are so expensive on some platforms in
terms of real memory or swap space or something else that real pain is
inevitable when you have more than a few processes only handling a small
number of requests.

The use of an array for the scoreboard exacerbates this because it
artificially limits the number of requests that can be handled in new
(squatting) processes.

Mime
View raw message