On 12/3/21 2:25 PM, yla...@apache.org wrote:
> Author: ylavic
> Date: Fri Dec 3 13:25:51 2021
> New Revision: 1895553
>
> URL: http://svn.apache.org/viewvc?rev=1895553&view=rev
> Log:
> mpm_event: Follow up to r1894285: new MaxSpareThreads heuristics.
>
> When at MaxSpareThreads, instead of deferring the stop if we are close to
> active/server limit let's wait for the pending exits to complete.
>
> This way we always and accurately account for slow-to-exit processes to
> avoid filling up the scoreboard, whether at the limits or not.
Just as a comment in case users will report it: This can slow down process
reduction even if far away from the limits:
Previously each call to perform_idle_server_maintenance killed off one process
if there was one to kill from the spare threads
point of view. Now it could take more calls as the process killed by the
previous call to perform_idle_server_maintenance
might not have died when we return to perform_idle_server_maintenance and thus
preventing to kill another one. Hence we won't have
multiple processes dying in parallel when we want to reduce processes due to
too much spare threads.
This can cause situations that if we kill a slow dying process first we will
have completely idle processes floating around for
quite some time.
Regards
Rüdiger
