httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 62009] scoreboard is full with worker MPM
Date Thu, 18 Jan 2018 13:58:31 GMT

--- Comment #6 from Yann Ylavic <> ---
(In reply to Armin Abfalterer from comment #3)
> Yann, by applying the patch surplus processes are terminated immediately,
> great!

Nice, will commit it and propose a backport for 2.4.x.

> Not sure if the
> "scoreboard is full" error cannot still occur.

I think it can, we made improvements in the event MPM lately for a better reuse
of scoreboard entries on graceful stop/restart, but AFAIK not in the worker
I think there is a workaround for this though, I'm mainly copying a comment I
made in another PR regarding this:

You probably want to "oversize" ServerLimit w.r.t. MaxRequestWorkers and
ThreadsPerChild, such that there is room in the scoreboard for gracefully
restarting processes (without interfering with the new generation ones).
This relaxes the usual/strict "MaxRequestWorkers = ServerLimit *
ThreadsPerChild" formula to take reloads into account. For example, if
MaxRequestWorkers should be 1000 (adapt to your needs), something like
ThreadLimit = ThreadsPerChild = 50 and ServerLimit = 50 (instead of 20) leaves
room for 2.5 simultaneous reloads, or one/two reload and some
MaxConnectionsPerChild/MaxSpareThreads kicking at the same time.

(In reply to Yann Ylavic from comment #1)
> Thanks Armin for the detailed report.

I think i didn't insist enough there, that's a really great report and analysis
that nailed an issue which possibly bites httpd since a while now for some
configurations, not only http2 (not negligible today) but also probably
mod_watchdog or any (third-party) that also make use of threads in children
We may have worked around this issue with some (heavier) MPM
fixes/optimizations, mod_http2 changes, and/or configuration advides
(MaxRequestsPerChild 0, large MaxSpareThreads...), but that didn't completely
close the door.
Good thing that it is now, thanks (again) a bunch Armin!

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message