httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
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

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.


View raw message