2016-06-06 16:48 GMT+02:00 Houser, Rick <rick.houser@xxxxxxxxxxx>:> 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.This time I should say sorry for the huge delay :)I started an email thread in dev@ as follow up to your questions [1] and Yann proposed a new MaxSpareThreads limit as you suggested in [2]. Credits to you for the idea of course, thanks a lot!I am going to update the related docs soon to warn users about how ListenCoresBucketsRatio changes the (Min|Max)SpareThreads calculations.Luca
|