httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: Threaded and ps->quiescing
Date Tue, 31 Jul 2001 20:45:45 GMT
"GUMMALAM,MOHAN (HP-Cupertino,ex2)" wrote:
> 
> Hi Greg:  Although the patch you sent fixes the problem of multiple pods,
> there are still some problems.  With the following configuration:
> 
> StartServers         6
> MinSpareThreads      5
> MaxSpareThreads     50
> 
> one would expect that when I start the web-server, since I have 6 processes,
> hence 150 threads (all of them idle), the MaxSpareThreads is exceeded.  This
> should result in the killing of 4 spare processes.  This does not happen.  A
> "ps" will show that all the 6 processes are still around.
> 
> The explanation is as follows, the p_i_s_m() would send 4 pods to kill the 4
> spare processes, so that there are only 2 processes running.  While this is
> the correct behaviour, the processes which have recd the pod do not die
> immediately.

yeah, I'm aware of the problems that happen when you don't have incoming
requests.  Do you ever see any problems where we quit serving pages?

> Again, the patch that Justin re-posted, with two mutexes - per-process and
> server-wide - resolves the problem completely. (I say almost, as there is
> still a small timing window between two consecutive runs of p_i_s_m() and
> updating the quiescing flag within the worker_thread() routine).  Both the
> fixes together - yours and Justin's - will fix the problem.

yes, but at the expense of an extra mutex.  I don't care too much about
the syscall itself but do care about the extra blocking/unblock/dispatch
for lightweight requests.  That can hurt more than you might think, due
to extra L1/L2 cache misses.

actually, it wouldn't need to be an extra syscall/block/unblock/dispatch
on platforms with no global mutex, if we change the existing accept
mutex to be cross process only.  That would give us the same model we
had over a year ago, which wasn't bad in retrospect.

That leave the question about what to do with platforms which do have a
native global mutex.  In this case, another mutex will add extra
blocking + dispatch + cache miss overhead.  dunno, maybe treat them
identically to keep the code simple, especially since our direction is
worker.  

Does HP-UX have global mutexes that can be used here?  If so, do you
care about the extra dispatch on your boxes?

> The patch Justin posted is with the new functions ap_mpm_pod_check() etc.  A
> similar patch with check_pipe_of_death() routines themselves could be used
> too - if you need, I could post that.

I'm not too worried about the details as long as it's clean, makes
something work better, and doesn't break or degrade other things.

Greg

Mime
View raw message