2016-06-06 16:48 GMT+02:00 Houser, Rick <rick.hou...@jackson.com>: > > 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 [1]: https://lists.apache.org/thread.html/53a4179f4afe9d1618a4475fa351f1e0ad141d8539beaf4f8332a96a@%3Cdev.httpd.apache.org%3E [2]: http://svn.apache.org/r1750218
