httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: Single listener - multi-worker
Date Sun, 29 Jul 2001 14:11:36 GMT
On Saturday 28 July 2001 15:18, Justin Erenkrantz wrote:
> On Sat, Jul 28, 2001 at 02:55:50PM -0400, Greg Ames wrote:
> > This problem occurs when incoming connections dry up, mostly in
> > non-production environments (therefore it's not real high on my priority
> > list, but whatever).  If worker processes aren't exiting quickly enough,
> > before starting with the SIGTERMs, check the scoreboard to see how many
> > processes don't have the new generation number (restarts only), pid ==
> > 0, quiescing, or a "G" somewhere in the worker_scores.  Send that many
> > dummy connects.  But don't bother with this if the dummy connect sender
> > ever times out, because we're probably overloading the kernel's
> > connection queue.
> You have no way of guaranteeing that your targeted threads (from the
> old generation) will receive the requests.
> Oh, maybe you want to do this before spawning the new processes in the
> case of a restart?  That's an option.  I think it's better to go to a
> single listener/process model, but that's me.  What about when you hit
> MaxRequestsPerChild?

That's not an option, and it doesn't really solve the problem.  :-)  Two reasons why this
doesn't work.  Reason 1)  Think of a time when the server is really getting hit hard.  If
try to shutdown every thread before restarting any processes, then you haven't really done

a graceful restart, because there was a time when you hadn't created any new children, but
you had started to kill off old ones.  Reason 2) think MaxRequestsPerChild.  In this case,
aren't shutting down all of the children, but we have to treat it like a graceful restart
for one
child process.  How do I wake up just the threads in that one child?


Ryan Bloom               
Covalent Technologies

View raw message