httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "GUMMALAM,MOHAN (HP-Cupertino,ex2)" <mohan_gumma...@hp.com>
Subject RE: tarballs are up
Date Tue, 31 Jul 2001 00:13:40 GMT
Greg:  Though I haven't completed testing the fix you suggested, I am
certain it would resolve the situation of multiple pods being sent.  I had a
pretty similar suggestion, which I had sent to the list a while back, and
hence my conviction that this will work.  I'll let you know what comes
through!
Thanks,
M

> -----Original Message-----
> From: Greg Ames [mailto:gregames@remulak.net]
> Sent: Monday, July 30, 2001 5:02 PM
> To: new-httpd@apache.org
> Subject: Re: tarballs are up
> 
> 
> "GUMMALAM,MOHAN (HP-Cupertino,ex2)" wrote:
> > 
> > -1 for beta
> > 
> > Was able to build and run it on HP-UX on PA-RISC -- with problems.
> > 
> > It still exhibits the same problem as was evident in 2.0.19 
> and later
> > releases, there is only 1 process up and running, (apart 
> from the cgid and
> > the watchdog process).  The configuration I used were as follows:
> > 
> > StartServers         6
> > MinSpareThreads      5
> > MaxSpareThreads     50
> > ThreadsPerChild     25
> > MaxRequestsPerChild  0
> > 
> > This behaviour on a running system would be as follows.  At 
> peak load, say a
> > webserver is serving 130 simultaneous request => I have 6 
> worker processes
> > running, a total of 150 threads.  At some point later, the 
> load (suddenly)
> > falls down to say, 90 requests => 60 spare threads.  The 
> current logic would
> > cause the p_i_s_m() to send a pod, to kill one process.  
> Since all the
> > processes are busy serving requests, the process which recd 
> the pod will not
> > die immediately.  Hence, p_i_s_m() will continue sending 
> pods.  Eventually
> > all the processes will die (and almost all of them 
> simultaneously).  And
> > finally, there will be 0 processes running.
> 
> hmmm, a lot of this was broken by the removal of the
> idle_thread_count_addition logic from p_i_s_m in revision 1.43 of
> threaded.c on July 3, while I was on a sailboat.  It is broken in the
> worker MPM as well.  If you can get mod_status to run, you 
> will see "G"s
> in the scoreboard when this hits.
> 
> This should fix threaded.  Cliff & Paul, this may well take 
> care of the
> bad stuff you're seeing.  I'll beat on it & commit fixes 
> after supper. 
> Sorry I didn't figure it out sooner.
> 
> Index: server/mpm/threaded/threaded.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/server/mpm/threaded/threaded.c,v
> retrieving revision 1.51
> diff -u -d -b -r1.51 threaded.c
> --- server/mpm/threaded/threaded.c      2001/07/28 23:39:07     1.51
> +++ server/mpm/threaded/threaded.c      2001/07/30 22:58:31
> @@ -1010,6 +1010,7 @@
>              */
>             if (status <= SERVER_READY && status != SERVER_DEAD &&
>                      ps->generation == ap_my_generation &&
> +                    !ps->quiescing &&
>                   /* XXX the following shouldn't be necessary if we
> clean up
>                    *     properly after seg faults, but we're 
> not yet   
> GLA
>                    */
> 
> Greg
> 

Mime
View raw message