On 12/2/21 4:32 PM, Yann Ylavic wrote:
> On Wed, Dec 1, 2021 at 5:19 PM Ruediger Pluem <rpl...@apache.org> wrote:
>>
>> On 12/1/21 3:59 PM, Eric Covener wrote:
>>>
>>> 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);
>
> Or this:
> --- server/mpm/event/event.c (revision 1895394)
> +++ server/mpm/event/event.c (working copy)
> @@ -3195,13 +3195,15 @@ static void perform_idle_server_maintenance(int ch
> * XXX depending on server load, later be able to resurrect them
> * or kill them
> */
> - if ((retained->total_daemons <= active_daemons_limit
> - && retained->total_daemons < server_limit)
> + if (retained->total_daemons < active_daemons_limit
> /* The above test won't transition from true to false until a
> child
> - * 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) {
> + * exits by itself (i.e. old generation or MaxRequestsPerChild),
> so
> + * the below test makes sure that the situation unblocks when the
> + * load drops significantly and there are no child of an old gen
> + * occupying the scoreboard already (above active_daemons_limit)
> so
> + * to avoid another squatter potentially slow to exit too. */
> + || (retained->total_daemons == active_daemons_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);
> ?
> It would unblock the situation only if/when there are no old gen
> processes in the scoreboard, though it'd works only if ServerLimit >
> active_daemons_limit (if they are equals, we can't/don't account for
> quiescing processes).
>
> Or maybe we could simply:
> --- server/mpm/event/event.c (revision 1895394)
> +++ server/mpm/event/event.c (working copy)
> @@ -3186,8 +3186,8 @@ static void perform_idle_server_maintenance(int ch
> * requests. If the server load changes many times, many such
> * gracefully finishing processes may accumulate, filling up the
> * scoreboard. To avoid running out of scoreboard entries, we
> - * don't shut down more processes when the total number of processes
> - * is high, until there are more than max_workers/4 idle threads.
> + * don't shut down more processes if there are quiescing ones
> + * already (i.e. retained->total_daemons > active_daemons).
> *
> * XXX It would be nice if we could
> * XXX - kill processes without keepalive connections first
> @@ -3195,13 +3195,7 @@ static void perform_idle_server_maintenance(int ch
> * XXX depending on server load, later be able to resurrect them
> * or kill them
> */
> - if ((retained->total_daemons <= active_daemons_limit
> - && retained->total_daemons < server_limit)
> - /* The above test won't transition from true to false until a
> child
> - * 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) {
> + if (retained->total_daemons == active_daemons) {
Wouldn't this effectively disable shutting down processes until we hit the
limit even if shrinking is desired far before we reach
this?
Example:
MaxRequestWorkers 1000
ThreadsPerChild 10
MinSpareThreads 10
MaxSpareThreads 30
Serverlimit 105
StartServers 2
In case the server gets 40 connections in parallel after startup it would spin
up to 5 processes if it gets idle afterwards it
would not shutdown children any longer.
Regards
Rüdiger
