As a real mitigation, maybe you could just use to mod_proxy and mod_proxy_balancer, also those are not third party modules and probably will render the same functionality you seek.
2016-06-27 9:50 GMT+02:00 Luca Toscano <toscano.l...@gmail.com>: > > > 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 > -- *Daniel Ferradal* IT Specialist email dferradal at gmail.com linkedin es.linkedin.com/in/danielferradal
