> So afaik the current 2.4 behavior is to enforce the minimum number of spare threads as
>
> ThreadsPerChild * num_buckets
>
> with num_buckets equal 1 if you are not leveraging SO_REUSEPORT (https://httpd.apache.org/docs/current/mod/mpm_common.html#listencoresbucketsratio). This means that if you have only > one busy thread the minimum number of httpd processes running will be always two. The new threshold is the more conservative:
>
> ThreadsPerChild * (num_buckets - 1) + num_buckets
>
> In your case, with num_buckets = 1, the lower bound of min spare threads is one, enabling the possibility to get down to only one httpd process (because the MinSpareThread lower bound won't > mess with your Min/MaxSpareThread settings anymore).
>
> More info in Yann's explanation: http://svn.apache.org/viewvc?view=revision&revision=1737447
>
> Let me know if it makes sense! If so, to fix your problem you'd need to apply the patch to the httpd source and recompile or wait for the backport to be reviewed/merged into the 2.4.x branch (and released afterwards).
>
> Luca
Sorry for the delay. My updated packages were installed over the weekend, and this does appear to fix the issue with me for the normal num_buckets = 1 case (all I use).
I'm far from an expert on the feature here, but wouldn't this behavior with num_buckets > 1 still leave the workload unbalanced? I thought the point per Yann's comment ("We want the number of children processes to be a multiple of the number of buckets so to optimally accept connections") was to balance the processes even between the listeners? I get that the initial startup case is fine, but in the case of num_buckets = 2, if thread usage gets to > 50%, this would seem to spawn a third, potentially unwanted process, leaving the workers unbalanced when the load really shouldn't be. I would have thought the way forward is leaving the idle thread minimum alone, forcing StartServers >= num_buckets, and enforcing a minimum process count = num_buckets. If process counts should be multiples of num_buckets, scaling any process count expands/shrinks by num_buckets would seem to be the way to accomplish this. I think this would also need a check to ensure that MaxSpareThreads >= MinSpareThreads + num_buckets * ThreadsPerChild + num_buckets.
|