On Fri, Dec 3, 2021 at 11:23 AM Ruediger Pluem <[email protected]> wrote: > > > > On 12/3/21 2:25 PM, [email protected] 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.
Could we base on max_daemons_limit instead? In the current impl we might still have ample slack space in the SB.
