httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Toscano <toscano.l...@gmail.com>
Subject Re: [users@httpd] Problems with Event MPM Performance Tuning in 2.4.18
Date Mon, 27 Jun 2016 07:50:27 GMT
2016-06-06 16:48 GMT+02:00 Houser, Rick <rick.houser@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

Mime
View raw message