You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@apache.org on 2001/07/02 00:49:34 UTC
cvs commit: httpd-2.0/server/mpm/threaded threaded.c
rbb 01/07/01 15:49:33
Modified: server/mpm/threaded threaded.c
Log:
Fix the threaded MPM perform_idle_server_maintenance. Basically, we now
count how many threads are actually idle, regardless of which process they
are in. This patch makes us use (min_spare_threads|max_spare_threads)
* number_of_running_servers to determine if we should kill of processes or
start new ones. This MPM no longer thrashes killing child processes as
soon as they are created, and the server continues to serve requests even
if the server is gracefully restarted and each child has one active thread.
Revision Changes Path
1.42 +2 -2 httpd-2.0/server/mpm/threaded/threaded.c
Index: threaded.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/threaded/threaded.c,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -d -b -w -u -r1.41 -r1.42
--- threaded.c 2001/06/28 22:15:53 1.41
+++ threaded.c 2001/07/01 22:49:31 1.42
@@ -1003,7 +1003,7 @@
}
ap_max_daemons_limit = last_non_dead + 1;
- if (idle_thread_count > max_spare_threads) {
+ if (idle_thread_count > max_spare_threads * ap_max_daemons_limit) {
/* Kill off one child */
char char_of_death = '!';
if ((rv = apr_file_write(pipe_of_death_out, &char_of_death, &one)) != APR_SUCCESS) {
@@ -1011,7 +1011,7 @@
}
idle_spawn_rate = 1;
}
- else if (idle_thread_count < min_spare_threads) {
+ else if (idle_thread_count < min_spare_threads * ap_max_daemons_limit) {
/* terminate the free list */
if (free_length == 0) {
/* only report this condition once */
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by rb...@covalent.net.
> > > After about another 10 minutes I started killing copies of b. Eventually I
> > > killed all of the bs and never saw any workers get idle cleaned up.
> >
> > How did you kill of b's?
>
> The old fashioned way - ctrl-c.
I must have missed something here. I assumed you meant b was a child
process, but it must not be. If you mean you killed your stress tool,
then this is what I would have expected. I fixed this bug this morning.
Basically, yesterday's tree didn't clean things up properly. Today's
does.
> > > In addition, the error_log had a number of "long lost child came home!" after
> > > the first SIG_WINCH and after the second SIG_WINCH I found a number of
> > > "child pid XXXXX exit signal Segmentation fault (11)" (some of which resulted
> > > in "long lost child came home!" messages - apparently they came home in a
> > > body bag).
> >
> > The "long lost child came home" messages are an unfortunate side effect,
> > and an easy one to solve. Basically, because we are replacing one child
> > with another before the parent's wait_for_child finds the one we replaced,
> > we lose that pid from the scoreboard, and we get this message. The easy
> > solution, is to have a single dimensional array in the parent that keeps
> > track of all child processes created, and watches for them to die. The
> > reason to separate this from the scoreboard, is that the parent doesn't
> > need this information in shared memory. The other solution, is to move
> > the pid to the worker_score. Either one works, but I am not likely to
> > implement either until after we tag and roll. This is not a fatal error
> > IMHO.
>
> Do I misunderstand here? There are quiescing workers whose slot has been
> reused? If that is true, doesn't that mean that when the worker finishes
> its task and tries to update its slot with request info that it is
> overwriting the info for the currently active worker in that same slot?
> This seems problematic to me.
You misunderstand. There are two portions to the scoreboard, parent and
worker scores. The parent score is re-used before the process dies,
because all of the important information is in the worker score. The
worker_score is not re-used. What is causing the "long lost child"
messages, is that the parent searches the parent_score for the pid. Since
that pid has been overwritten, it doesn't exist there anymore. There is
no danger of overwritting, because the new child process doesn't use a
worker_score that is currently in use.
> > > Also, the first SIG_WINCH doubled the memory footprint of Apache from 3.5 MB
> > > (in the first hour it grew from a little under 2 MB to a about 3.5) to almost
> > > 8 MB. Immediately after the second SIG_WINCH the size grew to 12 MB then
> > > quickly fell back to 8 MB, then continued to grow at a slow rate until I killed it.
> >
> > This is obviously a memory leak someplace. I don't know where right now,
> > and I am not going looking for it. Again, I didn't allocate any memory in
> > my patch, I just changed how we interpret the information we have.
>
> I thought this was relatively well known. I was just pointing out that, to my
> knowledge, it has never been recommended to run the threaded mpm with MRPC=0
> for this reason. Someday these leaks need to be tracked down, if possible.
The chances are the memory leak will always be there. Most thread
packages have leaks these days. Until the thread packages get cleaned up,
there isn't much we can do.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
rbb@covalent.net wrote:
> > After about another 10 minutes I started killing copies of b. Eventually I
> > killed all of the bs and never saw any workers get idle cleaned up.
>
> How did you kill of b's?
The old fashioned way - ctrl-c.
>
> > In addition, the error_log had a number of "long lost child came home!" after
> > the first SIG_WINCH and after the second SIG_WINCH I found a number of
> > "child pid XXXXX exit signal Segmentation fault (11)" (some of which resulted
> > in "long lost child came home!" messages - apparently they came home in a
> > body bag).
>
> The "long lost child came home" messages are an unfortunate side effect,
> and an easy one to solve. Basically, because we are replacing one child
> with another before the parent's wait_for_child finds the one we replaced,
> we lose that pid from the scoreboard, and we get this message. The easy
> solution, is to have a single dimensional array in the parent that keeps
> track of all child processes created, and watches for them to die. The
> reason to separate this from the scoreboard, is that the parent doesn't
> need this information in shared memory. The other solution, is to move
> the pid to the worker_score. Either one works, but I am not likely to
> implement either until after we tag and roll. This is not a fatal error
> IMHO.
Do I misunderstand here? There are quiescing workers whose slot has been
reused? If that is true, doesn't that mean that when the worker finishes
its task and tries to update its slot with request info that it is
overwriting the info for the currently active worker in that same slot?
This seems problematic to me.
>
> As for the seg faults. I believe those seg faults are caused by something
> other than the MPM. Take a look at the code I modified, none of it runs
> in the child process. Because I believe this is another problem, I am not
> going to try to fix it right now, we can attack these later, once the MPM
> is stable. Or somebody can attack them now, but it won't be me. :-)
Understood. I wasn't trying to pin the blame on you, just being complete in
identifying the problems I saw. For example, it is difficult for Apache to
do perform_idle_server_maintenance if there is no server any more, therefore
there won't be any idle cleanup after its gone...
>
> > Eventually I received a "Child XXXX returned a fatal error... Apache is exiting!"
> > message, so all of the top level processes are now owned by pid 1. Apache
> > continued serving pages for another hour until I killed it.
>
> This is a problem with the way Apache exits today. Basically, whenever
> Apache exits like this, it should first send a signal to the child
> processes. Today, it doesn't do that. If the parent decides to die, we
> need to be sure the children die too.
Ok, I agree here too. Again, just stating problems, not saying you had to fix it.
> > Also, the first SIG_WINCH doubled the memory footprint of Apache from 3.5 MB
> > (in the first hour it grew from a little under 2 MB to a about 3.5) to almost
> > 8 MB. Immediately after the second SIG_WINCH the size grew to 12 MB then
> > quickly fell back to 8 MB, then continued to grow at a slow rate until I killed it.
>
> This is obviously a memory leak someplace. I don't know where right now,
> and I am not going looking for it. Again, I didn't allocate any memory in
> my patch, I just changed how we interpret the information we have.
I thought this was relatively well known. I was just pointing out that, to my
knowledge, it has never been recommended to run the threaded mpm with MRPC=0
for this reason. Someday these leaks need to be tracked down, if possible.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by rb...@covalent.net.
Okay, I have just committed another change that should fix this. More
information below.
> After letting MRPC = 0 version run for an hour I did a SIG_WINCH and finally
> got over the 500 worker boundary. In fact, since all 500 workers were busy
> at the restart they were all left in place and another 500 started (now there
> are 1000 busy workers). After the initial near death experience on the server
> it resumed normal operation. It ran with 1000 busy workers for almost 30 minutes
> before I SIG_WINCHed it again. This time it ran up to about 1350 total workers
> and eventually, after about another 30 minutes, settled down to about 1225 workers.
This was my fault. My original patch looked like it solved the problem,
and based on the great research Bill did, I understood why it was needed.
Unfortunately, it attacked a symptom, not the real problem. The real
problem was the way we were counting idle_thread_count. That has been
fixed now, and the threaded MPM does now create and kill child processes
correctly.
> After about another 10 minutes I started killing copies of b. Eventually I
> killed all of the bs and never saw any workers get idle cleaned up.
How did you kill of b's?
> In addition, the error_log had a number of "long lost child came home!" after
> the first SIG_WINCH and after the second SIG_WINCH I found a number of
> "child pid XXXXX exit signal Segmentation fault (11)" (some of which resulted
> in "long lost child came home!" messages - apparently they came home in a
> body bag).
The "long lost child came home" messages are an unfortunate side effect,
and an easy one to solve. Basically, because we are replacing one child
with another before the parent's wait_for_child finds the one we replaced,
we lose that pid from the scoreboard, and we get this message. The easy
solution, is to have a single dimensional array in the parent that keeps
track of all child processes created, and watches for them to die. The
reason to separate this from the scoreboard, is that the parent doesn't
need this information in shared memory. The other solution, is to move
the pid to the worker_score. Either one works, but I am not likely to
implement either until after we tag and roll. This is not a fatal error
IMHO.
As for the seg faults. I believe those seg faults are caused by something
other than the MPM. Take a look at the code I modified, none of it runs
in the child process. Because I believe this is another problem, I am not
going to try to fix it right now, we can attack these later, once the MPM
is stable. Or somebody can attack them now, but it won't be me. :-)
> Eventually I received a "Child XXXX returned a fatal error... Apache is exiting!"
> message, so all of the top level processes are now owned by pid 1. Apache
> continued serving pages for another hour until I killed it.
This is a problem with the way Apache exits today. Basically, whenever
Apache exits like this, it should first send a signal to the child
processes. Today, it doesn't do that. If the parent decides to die, we
need to be sure the children die too.
> Also, the first SIG_WINCH doubled the memory footprint of Apache from 3.5 MB
> (in the first hour it grew from a little under 2 MB to a about 3.5) to almost
> 8 MB. Immediately after the second SIG_WINCH the size grew to 12 MB then
> quickly fell back to 8 MB, then continued to grow at a slow rate until I killed it.
This is obviously a memory leak someplace. I don't know where right now,
and I am not going looking for it. Again, I didn't allocate any memory in
my patch, I just changed how we interpret the information we have.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
More info:
After letting MRPC = 0 version run for an hour I did a SIG_WINCH and finally
got over the 500 worker boundary. In fact, since all 500 workers were busy
at the restart they were all left in place and another 500 started (now there
are 1000 busy workers). After the initial near death experience on the server
it resumed normal operation. It ran with 1000 busy workers for almost 30 minutes
before I SIG_WINCHed it again. This time it ran up to about 1350 total workers
and eventually, after about another 30 minutes, settled down to about 1225 workers.
After about another 10 minutes I started killing copies of b. Eventually I
killed all of the bs and never saw any workers get idle cleaned up.
In addition, the error_log had a number of "long lost child came home!" after
the first SIG_WINCH and after the second SIG_WINCH I found a number of
"child pid XXXXX exit signal Segmentation fault (11)" (some of which resulted
in "long lost child came home!" messages - apparently they came home in a
body bag).
Eventually I received a "Child XXXX returned a fatal error... Apache is exiting!"
message, so all of the top level processes are now owned by pid 1. Apache
continued serving pages for another hour until I killed it.
Also, the first SIG_WINCH doubled the memory footprint of Apache from 3.5 MB
(in the first hour it grew from a little under 2 MB to a about 3.5) to almost
8 MB. Immediately after the second SIG_WINCH the size grew to 12 MB then
quickly fell back to 8 MB, then continued to grow at a slow rate until I killed it.
I failed to capture a copy of the status while all 500 or 1000 of the workers
were busy, but I did catch a couple at the end when I started shutting things
down.
The first table below was taken after both SIG_WINCHes and with 3 of the copies
of b killed (the top level Apache process has already died):
Server Version: Apache/2.0.20-dev (Unix)
Server Built: Jul 2 2001 13:21:22
Current Time: Monday, 02-Jul-2001 17:10:44 EDT
Restart Time: Monday, 02-Jul-2001 14:51:19 EDT
Parent Server Generation: 2
Server uptime: 2 hours 19 minutes 25 seconds
Total accesses: 2231015 - Total Traffic: 61.3 GB
CPU Usage: u927.47 s2424.57 cu.16 cs2 - 40.1% CPU load
267 requests/sec - 7.5 MB/second - 28.8 kB/request
751 requests currently being processed, 474 idle servers
_WWW___WWWW_WW____W__W_WW_____WWW_WW_WW_W_WWWW_W___WWWW_W__W__W_
_WW__W_WW__W__W_______W__WWS__WS_WW_............................
................................................................
.........W.WW._..WWWWW.___WWW_W_WW____W__W___WWWS_WS_WWWRW......
................................................................
................................................................
................_W_____W__WW__W__W___W__W____WWWWWW_WW__WWW_W__W
WWSWR.W_RW.._W.._W_W_.W..WR...__.WW.W_R_WWWWRR._R_RWWWWWWWW__WWW
WWWW_WW_W__W_W__WWWWWWW_WWW_W_WW__WWW____WW__WWW_W_WW___WWWW_WWW
WWW_W__WW_WWWWW_WWW__WW_W_WW__WWW___W_____W__WWW__W___WWW_W____W
W_W_W____W_W___WW_WW_W__W__W__W_WW_WWW_WWWWW__WW_W___W___WW__W_W
W_W_W_WWW__W_WW_WW_W_W___WWW___WWWWWW__W__W___W__.WW_W_W__W_WSWW
S___W.W_W.WW______W___WW_W._W_W.W_W_WW____WWW_WWW_WWWWW___W_WW_W
__WW_W_WWW_WWWWWW_WW_WWWW_W__WWW_WW__WWW_WWW_WWWWWW______WWWWWWW
WW_WWWW____WW__WW_W__WWWWWWWW_W_W_W___WW_WWW_WWWWW___WWW_WWW_WSW
WWWW__WWW_WWW_WWWW____WW_WWW_RWW___WWWWW__R_W_W_WWWW_W__W_WWW_W_
_WWWW_W_WW_W__WW_W_WW_WWWWWWWWWWWW_WWW_WWW__WWWWW____WWWRWRW_WW_
WWW_WWWW_WW_WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWW__WW_W_WW___WW_WWWW_WW___W_W_W_WW__WW_W_W_WWWWWWWWWWWWWWWWW
WWWRWWRWWWWWWWRRWWWWWWWWWRWWWWWWWWW_W_WWWWWW_WWWWW__WWWWWWWWWWWW
WWWWWWWWW_W_WWWWWWWW_KWW__W__WW_WW_R_W_WW__WWWWWW__W__WW_W_WW_W_
__WWWWW_WWWW__W______W_WWW__W___W__W_WW__WW_____WW__W_WW_W_WWWW_
_WW__W_W_W___W_WWWWWWW_W__WW__W_WWW_WR___WWW______W_W_WW_W_WW_WW
____WWWW_W____W__W_____W____....................................
................................................................
This second one was taken 20 minutes after the last of the copies
of b was killed off. The values did not change for the 10 minutes
prior to this status.
Server Version: Apache/2.0.20-dev (Unix)
Server Built: Jul 2 2001 13:21:22
Current Time: Monday, 02-Jul-2001 17:34:51 EDT
Restart Time: Monday, 02-Jul-2001 14:51:19 EDT
Parent Server Generation: 1
Server uptime: 2 hours 43 minutes 32 seconds
Total accesses: 2367446 - Total Traffic: 66.4 GB
CPU Usage: u1038.69 s2726.54 cu.17 cs2.44 - 38.4% CPU load
241 requests/sec - 6.9 MB/second - 29.4 kB/request
95 requests currently being processed, 1130 idle servers
___________________________________________________W_W_____W____
_______WW__W__W__________WWS__WS_W__............................
................................................................
.........W.WW._..WWWWW.___WWW_W_WW____W__W___WWWS_WS_WWWRW......
................................................................
................................................................
................______W_________________________________________
__SWR.W_RW.._W.._W_W_.W..WR...__.WW.W_R_WWWWRR._R_RW____________
________________________________________________________________
________________________________________________________________
________________________________________________________________
______________________________________________W__.WW_W_W__W_WSWW
S___W.W_W.WW______W___WW_W._W_W.________________________________
________________________________________________________________
______________________________________________________________S_
W_______________W________WW___W_______W_________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
________________________________________________________________
____________________________....................................
................................................................
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
Ryan,
I ran one of my abuse runs against the current cvs tree. This is the same
tests that I have been running (where the cyclic idle periods were discovered).
The httpd.conf values are as follows:
StartServer 10
MaxClients 30
MinSpareThreads 100
MaxSpareThreads 200
ThreadsPerChild 50
MaxRequestsPerChild 1000
and the values in mpm_default.h are as follows:
DEFAULT_START_DAEMON 3
DEFAULT_MAX_FREE_DAEMON 10
DEFAULT_MIN_FREE_DAEMON 3
HARD_SERVER_LIMIT 32
HARD_THREAD_LIMIT 50
DEFAULT_THREADS_PER_CHILD 50
The first thing that happens is that Apache starts up the 10*50 workers
and reports that "server reached MaxClients setting. consider raising the
MaxClients setting." This is strange since it obviously started 10*50
(I checked with gtop at the number of processes/threads under httpd).
The second, and more critical thing, is that after 2 minutes children
started segfaulting. By 10 minutes the server stopped serving pages.
By 12 minutes there were no more processes left. All had segfaulted.
I have everything set to log core files to /tmp and have space there, but
no files got logged. In fact I have received core files before. But nothing
here. I'm checking into this.
I have 13 copies of Jeff Trawick's b program running on 7 different machines.
Apache is running on an eigth machine. The command line for the b programs is:
./b -c 100 -n 2559907 -f /tmp/replay.list -v
Third, if I run the same run but with MaxRequestsPerChild set to 0 (infinite)
It seems to run (for at least an hour) steadily at 200+ requests persecond
at over 3.5 MB/sec, but the memory footprint of httpd has been growing by about
2k every 5 seconds.
Finally, no matter how hard I try I cannot get it to ever go above 500 workers.
Even though I said it could start up to MaxClients = 30 * ThreadsPerChild = 50
= a total of 1500 workers. It starts the initial 10*50 and never rises above that.
If I have time later I will look into where the core files are and where it is dieing.
I just wanted to get this note in as soon as possible.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by Cliff Woolley <cl...@yahoo.com>.
On Sun, 1 Jul 2001 rbb@covalent.net wrote:
> Okay. I would like to tag/roll as soon as possible though. Let's say I
> will tag/roll at 10:00 PST tomorrow morning unless somebody speaks up.
Thanks.
> I know this goes against the tag, and we'll test afterwards, but I
> want this release to be useful, and I would really like a beta out of
> it. :-)
My thoughts exactly...
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by rb...@covalent.net.
Okay. I would like to tag/roll as soon as possible though. Let's say I
will tag/roll at 10:00 PST tomorrow morning unless somebody speaks up. I
know this goes against the tag, and we'll test afterwards, but I want this
release to be useful, and I would really like a beta out of it. :-)
Ryan
On Sun, 1 Jul 2001, Cliff Woolley wrote:
> On Sun, 1 Jul 2001 rbb@covalent.net wrote:
>
> > > Yes, definitely go to 2.0.20. Besides the other changes that have gone in
> > > since .19, .19 was announced to current-testers when it was rolled... no
> > > sense adding to the confusion by having two .19's. Numbers are cheap.
> > > =-)
> >
> > I'm not rolling until the current problem with the intraprocess locks is
> > fixed. I'll try to get to it soon-ish. If somebody wants to beat me to
> > it, feel free.
>
> Please hold off on tagging until tomorrow so I can have some time to
> test, particularly mod_file_cache...
>
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
>
>
>
>
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by Cliff Woolley <cl...@yahoo.com>.
On Sun, 1 Jul 2001 rbb@covalent.net wrote:
> > Yes, definitely go to 2.0.20. Besides the other changes that have gone in
> > since .19, .19 was announced to current-testers when it was rolled... no
> > sense adding to the confusion by having two .19's. Numbers are cheap.
> > =-)
>
> I'm not rolling until the current problem with the intraprocess locks is
> fixed. I'll try to get to it soon-ish. If somebody wants to beat me to
> it, feel free.
Please hold off on tagging until tomorrow so I can have some time to
test, particularly mod_file_cache...
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by rb...@covalent.net.
On Sun, 1 Jul 2001, Cliff Woolley wrote:
> On Sun, 1 Jul 2001 rbb@covalent.net wrote:
>
> > There were a lot of changes since that tag was laid. I wouldn't have a
> > problem just retagging that file if we had done everything in a few hours,
> > and nothing else had been committed. Since it took a few days, I do not
> > believe this is a good idea. We are better off just tagging as 2.0.20,
> > IMNSHO.
>
> Yes, definitely go to 2.0.20. Besides the other changes that have gone in
> since .19, .19 was announced to current-testers when it was rolled... no
> sense adding to the confusion by having two .19's. Numbers are cheap.
> =-)
I'm not rolling until the current problem with the intraprocess locks is
fixed. I'll try to get to it soon-ish. If somebody wants to beat me to
it, feel free.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by Cliff Woolley <cl...@yahoo.com>.
On Sun, 1 Jul 2001 rbb@covalent.net wrote:
> There were a lot of changes since that tag was laid. I wouldn't have a
> problem just retagging that file if we had done everything in a few hours,
> and nothing else had been committed. Since it took a few days, I do not
> believe this is a good idea. We are better off just tagging as 2.0.20,
> IMNSHO.
Yes, definitely go to 2.0.20. Besides the other changes that have gone in
since .19, .19 was announced to current-testers when it was rolled... no
sense adding to the confusion by having two .19's. Numbers are cheap.
=-)
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by rb...@covalent.net.
On Sun, 1 Jul 2001, Justin Erenkrantz wrote:
> On Sun, Jul 01, 2001 at 03:51:43PM -0700, rbb@covalent.net wrote:
> > On 1 Jul 2001 rbb@apache.org wrote:
> >
> > > rbb 01/07/01 15:49:33
> > >
> > > Modified: server/mpm/threaded threaded.c
> > > Log:
> > > Fix the threaded MPM perform_idle_server_maintenance. Basically, we now
> > > count how many threads are actually idle, regardless of which process they
> > > are in. This patch makes us use (min_spare_threads|max_spare_threads)
> > > * number_of_running_servers to determine if we should kill of processes or
> > > start new ones. This MPM no longer thrashes killing child processes as
> > > soon as they are created, and the server continues to serve requests even
> > > if the server is gracefully restarted and each child has one active thread.
> >
> > This patch should fix the threaded MPM. If people will test it over the
> > next few hours, I will roll 2.0.20 late tonight. I plan to wait about 3-4
> > hours before I roll, so that people can comment on if this solved their
> > problem or not.
>
> Can't we just retag that one file (threaded.c) as APACHE_2_0_19
> (whatever) and reroll? Nobody but the "few" of us on here know about
> 2.0.19, right? -- justin
There were a lot of changes since that tag was laid. I wouldn't have a
problem just retagging that file if we had done everything in a few hours,
and nothing else had been committed. Since it took a few days, I do not
believe this is a good idea. We are better off just tagging as 2.0.20,
IMNSHO.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sun, Jul 01, 2001 at 03:51:43PM -0700, rbb@covalent.net wrote:
> On 1 Jul 2001 rbb@apache.org wrote:
>
> > rbb 01/07/01 15:49:33
> >
> > Modified: server/mpm/threaded threaded.c
> > Log:
> > Fix the threaded MPM perform_idle_server_maintenance. Basically, we now
> > count how many threads are actually idle, regardless of which process they
> > are in. This patch makes us use (min_spare_threads|max_spare_threads)
> > * number_of_running_servers to determine if we should kill of processes or
> > start new ones. This MPM no longer thrashes killing child processes as
> > soon as they are created, and the server continues to serve requests even
> > if the server is gracefully restarted and each child has one active thread.
>
> This patch should fix the threaded MPM. If people will test it over the
> next few hours, I will roll 2.0.20 late tonight. I plan to wait about 3-4
> hours before I roll, so that people can comment on if this solved their
> problem or not.
Can't we just retag that one file (threaded.c) as APACHE_2_0_19
(whatever) and reroll? Nobody but the "few" of us on here know about
2.0.19, right? -- justin
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by rb...@covalent.net.
On 1 Jul 2001 rbb@apache.org wrote:
> rbb 01/07/01 15:49:33
>
> Modified: server/mpm/threaded threaded.c
> Log:
> Fix the threaded MPM perform_idle_server_maintenance. Basically, we now
> count how many threads are actually idle, regardless of which process they
> are in. This patch makes us use (min_spare_threads|max_spare_threads)
> * number_of_running_servers to determine if we should kill of processes or
> start new ones. This MPM no longer thrashes killing child processes as
> soon as they are created, and the server continues to serve requests even
> if the server is gracefully restarted and each child has one active thread.
This patch should fix the threaded MPM. If people will test it over the
next few hours, I will roll 2.0.20 late tonight. I plan to wait about 3-4
hours before I roll, so that people can comment on if this solved their
problem or not.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: cvs commit: httpd-2.0/server/mpm/threaded threaded.c
Posted by rb...@covalent.net.
On 1 Jul 2001 rbb@apache.org wrote:
> rbb 01/07/01 15:49:33
>
> Modified: server/mpm/threaded threaded.c
> Log:
> Fix the threaded MPM perform_idle_server_maintenance. Basically, we now
> count how many threads are actually idle, regardless of which process they
> are in. This patch makes us use (min_spare_threads|max_spare_threads)
> * number_of_running_servers to determine if we should kill of processes or
> start new ones. This MPM no longer thrashes killing child processes as
> soon as they are created, and the server continues to serve requests even
> if the server is gracefully restarted and each child has one active thread.
This patch should fix the threaded MPM. If people will test it over the
next few hours, I will roll 2.0.20 late tonight. I plan to wait about 3-4
hours before I roll, so that people can comment on if this solved their
problem or not.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------