Never, the server is not even under high load. There
are several thousand vhosts, it is about shared webhosting.
This is what server-status says:
PID Connections Threads Async connections
total accepting busy idle writing keep-alive closing
21388 257 yes 44 20 0 171 44
11454 2 no 0 0 0 0 0
16555 1 no 0 0 0 0 0
Sum 260 44 20 0 171 44
That one PID 11454 has "2" connections, 16555 has "1", all other
values are 0, I guess it should become killed? - but it does not,
it stays like this for a while (I don't know on what this "while" depends on).
At this point all 3 rows are filled with stuff, such as:
WWW_W_WWWWWW_WW_W_W_W_WW__WWW__WW__WWWWWW__WWW__W__W_RWWWWRWWWWW GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG GGGGGGGGGGGGGGGLGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG But as you see, due to several _ this means that there are not all 192 busy, in fact: 105 requests/sec - 2.5 MB/second - 24.8 kB/request 44 requests currently being processed, 20 idle workers WHY can no others be used? With the statement above it means that 128 (which is 192-64) workers are unused because they should become killed already, to spawn new ones, these are the ones in the 2. and 3. row with "G"s. -- So the rest is occupied with "G". In Apache 2.2 I used MPM_event as well, this obviously never occured because the both PIDs above which are showing G only showed just dots in that case, now after one PID should be finished, all slots become occupied with G, which obviously causes a full scoreboard. I would consider this a bug, a serious one for my case, since it often occurs (~1-3 times per hour) that the server stops accepting new requests, just because of that full scoreboard, where the server is neither busy, nor do I see what configuration directive should be configured badly. Again: KeepAlive On ListenBacklog 4095 Timeout 20 KeepAliveTimeout 8 MaxKeepAliveRequests 16192 MaxRanges 200 MaxRangeOverlaps 20 MaxRangeReversals 20 GracefulShutdownTimeout 6 LimitInternalRecursion 10 LimitRequestFieldSize 4094 LimitRequestFields 40 LimitRequestLine 4094 LimitXMLRequestBody 786432 MaxRequestWorkers 192 ServerLimit 3 StartServers 2 MaxMemFree 2048 MinSpareThreads 64 MaxSpareThreads 64 ThreadLimit 128 ThreadsPerChild 64 MaxConnectionsPerChild 10240 AsyncRequestWorkerFactor 10I assumed AsyncRequestWorkerFactor to have something to do with it, I raised it from 2 (default) to 10, no change. By the way: after some time (in this case above both) PIDs become killed finally, releasing 2x64 slots in the scoreboard, the waring messages vanish and the server can respond again well to requests. In the interest of finding a workaround until this is fixed: what configuration directives control that timeout or whatever, which cause these PIDs to become killed?
On Thu, Sep 6, 2012 at 7:06 PM, Sam <lennsen@xxxxxxxxx> wrote:
Yes, I still see such messages even after upgrading to 2.4.3
On Sun, Aug 19, 2012 at 8:25 AM, Sam <lennsen@xxxxxxxxx> wrote:I upgraded to Apache 2.4 and use mod_event on a server having average high load. My issue is that I am getting pretty much often the error message within the error log AH00485: scoreboard is full, not at MaxRequestWorkers What causes this? The server almost stops to handle new requests when this occurs. MaxRequestWorkers 192 ServerLimit 3 StartServers 2 MaxMemFree 2048 MinSpareThreads 64 MaxSpareThreads 64 ThreadLimit 64 ThreadsPerChild 64 MaxConnectionsPerChild 10240 AsyncRequestWorkerFactor 2
So you never have more than 192 simultaneous requests at any given time ???
|