httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gonyou, Austin" <aus...@coremetrics.com>
Subject RE: tarballs are up
Date Tue, 31 Jul 2001 00:11:46 GMT
OK...2_0_22 is up and running with PHP4. Not too shabby. No issues yet to
speak of. IPM actually works on that thing too! Anyway, I'm going to unscrew
php nuke on that part of the machine and report once that's done how it's
working. It's been good so far. Trying to start it again while it's up,
caused me a problem once though. Wouldnt' kill HTTPD, had to killall -9
httpd to get it to stop. 

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com 

> -----Original Message-----
> From: Greg Ames [mailto:gregames@remulak.net]
> Sent: Monday, July 30, 2001 7: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