Regarding normal traffic handling, where the thread count might change over
time, I can see your point. But with a 'static' state, such as right after
start up with no traffic, how would

  (idle_thread_count < min_spare_threads)

be triggered ? I would expect the thread count to be unchanging as there
are no reasons to shut down active threads - both since (MinSpareThreads <
MaxSpareThreads) and (idle_thread_count == min_spare_threads).



On Fri, Oct 18, 2013 at 5:19 PM, Jim Jagielski <[email protected]> wrote:

> The mojo for this, in both worker and event is:
>
>         (active_thread_count >= ap_daemons_limit * threads_per_child)
>
> which is only worried about if:
>
>         (idle_thread_count < min_spare_threads)
>
> On Oct 18, 2013, at 10:22 AM, Thomas Eckert <[email protected]>
> wrote:
>
> > Hey folks,
> >
> > there's been quite a few issues with the "scoreboard is full, not at
> MaxRequestWorkers" error log message. From what I've found all of them
> involved some sort of heavy traffic. I've been wondering about the root
> cause for this but now I have a reverse proxy showing this message right
> after starting up - no traffic involved at all.
> >
> > I'm getting the message for a simple reverse proxy with about a hundred
> virtual hosts which is strange because
> >
> > StartServers 3
> > ServerLimit 30
> > MaxClients 1500
> > MinSpareThreads 25
> > MaxSpareThreads 75
> > ThreadsPerChild 50
> > MaxRequestsPerChild 0
> >
> > doesn't look like it cannot handle 100 hosts without traffic. The vhosts
> themselves look like
> >
> > <VirtualHost 10.8.17.133:80>
> >         ServerName my_domain_3
> >         SSLProxyEngine On
> >         RequestHeader set X-Forwarded-Proto http
> >         <Location />
> >                 ProxyPass balancer://58be3a18b1c6590f106e3536d31d0447/
> lbmethod=bybusyness
> >                 ProxyPassReverse
> balancer://58be3a18b1c6590f106e3536d31d0447/
> >                 Require all granted
> >         </Location>
> > </VirtualHost
> >
> > which is really basic. There is only one virtual host with a "real"
> configuration (setup is part of a scalability test).
> >
> > Again, there is no traffic involved, it's happening right after start
> up. I checked the processes and the start up is clean, meaning there are no
> old left-overs that might interfere somehow.
> >
> > Any hints on how to debug this ?
>
>

Reply via email to