On 12/1/21 3:59 PM, Eric Covener wrote:
> On Wed, Dec 1, 2021 at 9:16 AM Ruediger Pluem <rpl...@apache.org> wrote:
>>
>>
>>
>> On 11/30/21 2:53 PM, Eric Covener wrote:
>>> On Fri, Oct 15, 2021 at 6:29 AM <yla...@apache.org> wrote:
>>>>
>>>> Author: ylavic
>
>>>
>>> But then I can't explain the PR this came from
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=65626
>>
>> The issue is that in the PR ServerLimit == MaxRequestWorkers /
>> ThreadsPerChild.
>> Once you reached ServerLimit and there are no dying children, child
>> processes will not be shutdown any longer.
>> From a quick glance this can only happen if ServerLimit == MaxRequestWorkers
>> / ThreadsPerChild. If it is larger
>> shutdown should start again some time as some children must be in the
>> process of dying.
>
> Thanks, that makes sense.
> I wonder if the patch here could maybe key off of whether there is
> slack space in ServerLimit or if
> retained->total_daemons == active_daemons_limit to avoid creating more
> slow to exit children when
> the new condition is not the only way out?
You mean something like:
Index: server/mpm/event/event.c
===================================================================
--- server/mpm/event/event.c (revision 1895463)
+++ server/mpm/event/event.c (working copy)
@@ -3201,7 +3201,8 @@
* exits by itself (i.e. MaxRequestsPerChild reached), so the below
* test makes sure that the situation unblocks when the load falls
* significantly (regardless of MaxRequestsPerChild, e.g. 0) */
- || idle_thread_count > max_workers/4 / num_buckets) {
+ || (active_daemons_limit == server_limit
+ && idle_thread_count > max_workers/4 / num_buckets)) {
/* Kill off one child */
ap_mpm_podx_signal(retained->buckets[child_bucket].pod,
AP_MPM_PODX_GRACEFUL);
Regards
Rüdiger
