httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: Suggested direction for fixing threaded mpm thread startup.
Date Mon, 23 Apr 2001 03:43:14 GMT

> > > > OK, it's swell for me.  Paul?
> > >
> > > Um...  This is an incredibly dangerous change.  This makes Apache shutdown
> > > one threaded process at a time.  I think we have all downloaded tarballs
> > > that are hundreds of megs, which can take a few hours to download.  What
> > > happens if while my server is serving one of those files, I need to do a
> > > graceful restart to re-config my server.  If the first process shutdown is
> > > the one with the thread serving a three hour request, then my server won't
> > > actually restart for 3 hours.
> > >
> > > Ryan
> > >
> >
> > I agree with you Ryan.  Haven't thought about this much over the weekend, but my
inclination is
> > 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
> > to overcommit processes to compensate for multiple processes being restarted at
once. Then as
> > 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
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
all but one thread in each of the first 10 processes have exited and the 2nd group of 10 go
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
pathological cases, even with the combined strategy.


View raw message