worker MPM: it sucks to have minimal MaxSpareThreads

[Jeff Trawick <tr...@gmail.com>]

Start with something like this:

MaxClients          150
...
MaxSpareThreads  75

in the default conf file, which is a very reasonable way to run.

Then realize you need to support boatloads more clients, so you bump
up MaxClients to 5000.  Now when load changes very slightly (as a
percentage of MaxClients), which happens continuously, the web server
will create or destroy a child process.  Okay, it works, but you can
remain stuck in the confusing state where there are multiple child
processes using the same process_score, and you can see lots more
httpd processes than you expect, and you can start worrying if you're
going to run out of paging/swap space since there are so many darn
httpd processes.  (A lot of these are terminating.)

Any comments on these two separate proposals?

a) "MaxSpareThreads auto"
the "auto" keyword means automatically set this to 50% of MaxClients;
stick this in Apache default conf file

b) tweak worker MPM to automatically bump the value of MaxSpareThreads
to at least 15% of MaxClients, with a warning written to the error log

Re: worker MPM: it sucks to have minimal MaxSpareThreads

[Bill Stoddard <bi...@wstoddard.com>]

Greg Ames wrote:
> Jeff Trawick wrote:
> 
>> Then realize you need to support boatloads more clients, so you bump
>> up MaxClients to 5000.  Now when load changes very slightly (as a
>> percentage of MaxClients), which happens continuously, the web server
>> will create or destroy a child process.  
> 
> 
>> b) tweak worker MPM to automatically bump the value of MaxSpareThreads
>> to at least 15% of MaxClients, with a warning written to the error log
> 
> 
> +1 to b), btw.
> 
> we've had offline discussions about optimizing MaxSpareThreads according 
> to the variance seen in busy threads, but that's for admins who know 
> what they're doing.  15% is pretty conservative and should help sites 
> with less experienced admins.
> 
> Greg

+1

Bill

Re: worker MPM: it sucks to have minimal MaxSpareThreads

[Greg Ames <gr...@remulak.net>]

Jeff Trawick wrote:

> Then realize you need to support boatloads more clients, so you bump
> up MaxClients to 5000.  Now when load changes very slightly (as a
> percentage of MaxClients), which happens continuously, the web server
> will create or destroy a child process.  

> b) tweak worker MPM to automatically bump the value of MaxSpareThreads
> to at least 15% of MaxClients, with a warning written to the error log

+1 to b), btw.

we've had offline discussions about optimizing MaxSpareThreads according to the 
variance seen in busy threads, but that's for admins who know what they're 
doing.  15% is pretty conservative and should help sites with less experienced 
admins.

Greg

Re: worker MPM: it sucks to have minimal MaxSpareThreads

[Jeff Trawick <tr...@gmail.com>]

On Mon, 7 Mar 2005 08:35:12 -0800, Aaron Bannert <aa...@clove.org> wrote:
> 
> On Mar 4, 2005, at 12:08 PM, Jeff Trawick wrote:
> > Any comments on these two separate proposals?
> >
> > b) tweak worker MPM to automatically bump the value of MaxSpareThreads
> > to at least 15% of MaxClients, with a warning written to the error log
> 
> I like this best, because is requires no action on the user's part
> to take advantage of the change.

same here
 
> Just so I understand the problem correctly, you're saying that
> when Worker is trying hard to stay near that MaxSpareThreads
> setting, and under a condition that pushes the server constantly
> up near that threshold (eg. when you have a sustained connection
> rate that is higher than MaxSpareThreads) then the turnover of
> connections causes Worker to kill and respawn children quickly,
> but that since the turnover is so quick you end up having children
> lingering around with one or two thread slots and essentially
> we approach the prefork scenario in terms of number of child
> processes. Is this correct?

yes, that is correct...  the more lengthy the response time, the worse
the problem gets

Thanks for your comments.

Re: worker MPM: it sucks to have minimal MaxSpareThreads

[Greg Ames <gr...@remulak.net>]

Aaron Bannert wrote:

> Just so I understand the problem correctly, 

> but that since the turnover is so quick you end up having children
> lingering around with one or two thread slots and essentially
> we approach the prefork scenario in terms of number of child
> processes. Is this correct?

in worker + event there is also the "squatting" logic where newly spawned 
children take over partially empty scoreboard slots in a non-intuitive manner. 
so excessive killing & spawning can lead into strange code paths and Bad Things 
that can't happen in prefork.

Greg

Re: worker MPM: it sucks to have minimal MaxSpareThreads

[Aaron Bannert <aa...@clove.org>]

On Mar 4, 2005, at 12:08 PM, Jeff Trawick wrote:
> Any comments on these two separate proposals?
>
> b) tweak worker MPM to automatically bump the value of MaxSpareThreads
> to at least 15% of MaxClients, with a warning written to the error log

I like this best, because is requires no action on the user's part
to take advantage of the change.

Just so I understand the problem correctly, you're saying that
when Worker is trying hard to stay near that MaxSpareThreads
setting, and under a condition that pushes the server constantly
up near that threshold (eg. when you have a sustained connection
rate that is higher than MaxSpareThreads) then the turnover of
connections causes Worker to kill and respawn children quickly,
but that since the turnover is so quick you end up having children
lingering around with one or two thread slots and essentially
we approach the prefork scenario in terms of number of child
processes. Is this correct?

-aaron