On Wed, Apr 13, 2016 at 6:27 PM, Stefan Fritsch <s...@sfritsch.de> wrote: > Maybe it would be better to remove the logic to re-use scoreboard > slots of processes which have already terminated some threads. > Instead, one could use the scoreboard area abore (MaxRequestWorkers / > ThreadsPerChild) more aggressively, and maybe even allocate some > additional slack space at startup.
Been helping a user affected by this, they got here after tuning around some OOM issues and are stuck with long ProxyTimeout values (a good recipe for this problem) Without understanding this very well, using the slack space (exclusively) does seem like a good idea to me. >There could be these config knobs: > - the max number of fully active processes (ServerLimit) We could also also leave this as MaxRequestWorkers /ThreadsPerChild. The slack would be defined by the difference from ServerLimit. This is also handy because it means ServerLimit really is the max active+exiting. > - the max number of gracefully finishing processes ("OldServerLimit"?) Maybe better to count threads here after your other changes? > - what to do if OldServerLimit is reached during a graceful restart: > * reduce the max number of fully active processes accordingly > * kill off old processes Maybe OldServerLimit could be the # of exiting processes (or threads) that are not counted against the limits, rather than something that is binary (either breached or not) GracefulShutdownTimeout could not be directly applied, but maybe we could have something similar applied only to get us back below OldServerLimit. > - what to do if OldServerLimit during normal operation: > * stop doing idle-cleanup of fully active processes [X] > * kill off old processes > > Hmm. Now that I think of it, I think we should really do [X] if there > are too many old processes. The only question is how to define too > many. I think OldServerLimit as more of a soft limit for countermeasures like this helps here too. The slack space itself is then the hard limit. -- Eric Covener cove...@gmail.com