bugzilla at apache
Oct 15, 2009, 9:25 AM
Post #2 of 2
(283 views)
Permalink
|
|
[Bug 45497] Scoreboard slot leaked using MaxRequestsPerChild and thread(s) do not exit gracefully
[In reply to]
|
|
https://issues.apache.org/bugzilla/show_bug.cgi?id=45497
--- Comment #4 from Jason Riffel <jason [at] cipreporting> 2009-10-15 09:25:40 UTC ---
I am also surprised that this has not been considered for inclusion in the
official release. If you run Apache on Windows and use modules, some times
those modules leak memory. Sure, I would like to fix those modules but that is
not always practical and that is why Apache implements MaxRequestsPerChild to
provide a work around to this wide spread issue by recycling processes to free
leaked memory transparently.
The current implementation in production for Win32 works as long as the threads
terminate gracefully - however, if a child thread becomes locked or takes too
long to shut down the thread is terminated but its thread slot is never
recovered.
The lack of recovery of all thread slots means that the next process never
leaves the startup state because it requires 100% of its threads to be started.
It will continue to serve requests while in the start up state but it will
never recyle processes again thus allowing the memory leaks to accumulate to a
point of failure.
IMHO - On Win32 if you are using Apache modules and are using
MaxRequestsPerChild your system is at risk of failure due to this defect. I
have attached a patch to fix this which has been running flawlessly in our
environment for well over a year now.
It is possible that this is a pattern which is replicated in other processor
modules - I did not check that myself.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe [at] httpd
For additional commands, e-mail: bugs-help [at] httpd
|
