httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: Suggested direction for fixing threaded mpm thread startup.
Date Mon, 23 Apr 2001 03:51:27 GMT

> > > I agree with you Ryan.  Haven't thought about this much over the weekend, but
my inclination is
> that
> > > a combination of strategies is required. First, split the scoreboard into two,
one for process
> > > management and one for status.  The process management scoreboard will be small
enough to enable
> us
> > > to overcommit processes to compensate for multiple processes being restarted
at once. Then as
> Greg
> > > suggests, put some bounds on the number of process that may be in restart.
> >
> > I am 100% on board with splitting the scoreboard.  I disagree with putting
> > bounds on the number of processes allowed in restart however.  I don't see
> > how it is possible to get around the problem outlined above.  I haven't
> > really thought it through though, so I could easily be missing something.
> >
> > Ryan
>
> I am thinking bounding restarting processes to avoid the pathological case. Example...
10 processes
> each with 100 threads, all 10 go into restart (actually pending shutdown) and we fork
10 more
> processes each with 100 threads as back ups.  We now have 20 processes active.  Now consider
that
> all but one thread in each of the first 10 processes have exited and the 2nd group of
10 go into
> restart. We now fork 10 more processes each with 100 threads for a total of 30 processes,
20 in some
> stage of shutdown.  Recurse and you see that we can run into a problem of too many processes,
in the
> worst case, 1000 processes each with a single active thread.
>
> Not quite sure how to handle shuttingdown a threaded server gracefully -and- guarantee
that no
> pathological cases, even with the combined strategy.

I don't think we can handle EVERY pathological case.  We don't try to
handle all the pathological cases with a prefork server.  I am not sure
that we need to handle the case outlined above, just because it can't be
solved.  I would rather allow the server to be re-configured as often as
possible, even if that means that occasionally a pathological case means
that we can't restart after say the tenth restart, until some of the
server's actually die.

I believe that is much better than having the server continue to run with
the old config after a restart.  However, that is just my opinion, and I
am fine being told I am incorrect in this.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message