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 you
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, we
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
_____________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
-----------------------------------------------------------------------------
