Hi Stefan,

On Thu, Apr 14, 2016 at 12:27 AM, Stefan Fritsch <[email protected]> wrote:
> On Monday 11 April 2016 18:12:43, Eric Covener wrote:
>> On Mon, Apr 11, 2016 at 4:59 PM,  <[email protected]> wrote:
>> > ServerLimit >= 10 * MaxRequestWorkers / ThreadsPerChild
>>
>> Hi Stefan -- I am curious -- prior to the recent patches, just
>> having the extra capacity in ServerLimit didn't help / didn't help
>> as much?
>
> No, without the patches attached to the PR, ServerLimit does not play
> any role for this issue. Only the scoreboard entries up to
> (MaxRequestWorkers / ThreadsPerChild) will ever be used.
>
> The state in 2.4 is that scoreboard entries of processes where some
> threads have already terminated would get re-used, but there is no
> code that terminate threads before the whole process terminates.

How about:

Index: server/mpm/event/event.c
===================================================================
--- server/mpm/event/event.c    (revision 1741696)
+++ server/mpm/event/event.c    (working copy)
@@ -2857,7 +2857,7 @@ static void perform_idle_server_maintenance(int ch
                 (status == SERVER_GRACEFUL);
             any_dead_threads = any_dead_threads || (status == SERVER_DEAD);
             all_dead_threads = all_dead_threads &&
-                (status == SERVER_DEAD || status == SERVER_GRACEFUL);
+                (status == SERVER_DEAD);

             /* We consider a starting server as idle because we started it
              * at least a cycle ago, and if it still hasn't finished starting
_

AIUI, that would (re)use *in priority* scoreboard entries of processes
*fully* idle.
So possibly admins could configure ServerLimit = N *
(MaxRequestWorkers / ThreadsPerChild), where N would be the number of
graceful restarts expected to not mix worker entries of old/new
generation processes.
N could be determined based on the frequency of graceful restarts and
average connections' duration (bounded by MaxKeepAliveRequests,
*Timeout, ...).
Spare scoreboard entries (ServerLimit - MaxRequestWorkers /
ThreadsPerChild) are quite cheap with today's memory capacities...
The current mixing logic would still apply when the above is
exhausted, but admins could increase N.

Regards,
Yann.

Reply via email to