Re: getting rid of 'server reached MaxClients setting' error
Since I get no further feedback, I'm going to commit this soon, unless someone objects/comments on it. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: getting rid of 'server reached MaxClients setting' error
Stas Bekman wrote:
I think this misleading error is really a bug in Apache:
I agree.
[Mon Apr 26 15:28:44 2004] [error] server reached MaxClients setting,
consider raising the MaxClients setting
It sounds like a one-off bug to me. It reports that error when the
number of workers is the same as MaxClients,
it's worse than that, I think.
which is perfectly fine. It
should only report a problem when a new request is coming in and there
are no free servers/threads to handle the request.
I've seen this recently while experimenting with event driven I/O built on top
of the worker MPM. It seems to happen when the parent is trying to increase the
number of child processes but they haven't initialized yet and the server is
temporarily out of worker threads. I didn't see the number of active workers
reach MaxClients. Re-examining the test that leads to the message:
else if (idle_thread_count min_spare_threads) { == cool
/* terminate the free list */
if (free_length == 0) { == insufficient
I'm a little rusty on this code, but looks like free_length is increased when
the code finds a process with at least one worker thread with SERVER_DEAD state
in the scoreboard. I don't see where it checks for MaxClients.
Greg
Re: getting rid of 'server reached MaxClients setting' error
[EMAIL PROTECTED] wrote:
Stas Bekman wrote:
I think this misleading error is really a bug in Apache:
I agree.
[Mon Apr 26 15:28:44 2004] [error] server reached MaxClients setting,
consider raising the MaxClients setting
It sounds like a one-off bug to me. It reports that error when the
number of workers is the same as MaxClients,
it's worse than that, I think.
which is perfectly fine. It should only report a problem when a new
request is coming in and there are no free servers/threads to handle
the request.
I've seen this recently while experimenting with event driven I/O built
on top of the worker MPM. It seems to happen when the parent is trying
to increase the number of child processes but they haven't initialized
yet and the server is temporarily out of worker threads. I didn't see
the number of active workers reach MaxClients. Re-examining the test
that leads to the message:
else if (idle_thread_count min_spare_threads) { == cool
/* terminate the free list */
if (free_length == 0) { == insufficient
I'm a little rusty on this code, but looks like free_length is increased
when the code finds a process with at least one worker thread with
SERVER_DEAD state in the scoreboard. I don't see where it checks for
MaxClients.
Thanks, Greg. Am I right to say that you now have an itch to scratch and get
it solved? :)
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: getting rid of 'server reached MaxClients setting' error
moving to [EMAIL PROTECTED]
Stas Bekman wrote:
I think this misleading error is really a bug in Apache:
I agree.
[Mon Apr 26 15:28:44 2004] [error] server reached MaxClients setting,
consider raising the MaxClients setting
It seems to happen when the parent is
trying to increase the number of child processes but they haven't
initialized yet and the server is temporarily out of worker threads.
I didn't see the number of active workers reach MaxClients.
Re-examining the test that leads to the message:
else if (idle_thread_count min_spare_threads) { == cool
/* terminate the free list */
if (free_length == 0) { == insufficient
I wasn't able to confirm the theory that this line is wrong. I stuck in an
assert() to force the parent to coredump right before issuing the message. Much
to my surprise I saw ap_daemons_limit (basically MaxClients/ThreadsPerChild,
after sanity checking and rounding) active child processes. I couldn't verify
the state of the worker threads at the instant the assert() hit from the dump
since the children continued to run and update the scoreboard while the parent
was dumping it.
Perhaps the parent should anticipate how many worker threads will eventually
become active after it forks/kills children, and to take this into account
before doing anything rash like forking or writing error messages. But that
will take some thought and this code is gnarly.
I'm a little rusty on this code,
I was able to confirm this theory :(
Thanks, Greg. Am I right to say that you now have an itch to scratch and
get it solved? :)
I have an itch but no good solution so far. Ideas/patches are welcome,
especially ones that simplify this code.
Greg
