httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject RE: Memory leak on Windows [Bugzilla #11427]
Date Tue, 17 Dec 2002 18:16:00 GMT
I am running 2.0.44-dev (latest snapshot in CVS from just a few minutes ago) and
I'm not able to recreate this problem. Have you tried the latest version of 2.0
(CVS HEAD)?  Just for fun, try disabling keep-alive connections or set
MaxKeepAliveRequests to a small value (maybe from the default of 100 to 10) and
report back the results.


> Hi,
> I'm still trying to track the cause of this problem down, and I'm hoping
> somebody around here can help me.
> To summarize, I'm seeing Apache's memory footprint grow abnormally large
> on Windows when using CGIs.  The size of the growth seems to be
> proportional to the amount of data printed to stdout from the CGI.
> Some sample data:
>  - With 16 threads and 1 meg sent to stdout, combined physical and virtual
>    memory reaches about 70 megs after hammering the server for several
>    minutes
>  - If I increase the amount of stdout data to 2 megs, the process grows to
>    about 130 megs within another few minutes.
> I've spent the last few days reviewing the code, and I'm a bit confused
> about the mpm_winnt pool cleanup code.  I haven't spent a lot of time
> reading the code in the past, so there's a good chance that I've just
> missed something.  As far as I can tell, ap_read_request() creates the
> request pool, but nothing explicitly cleans it up.  Instead, it looks like
> mpm_recycle_completion_context() clears the ptrans pool the next time the
> thread handles a request.  While this seems funny to me, I don't see why
> some of the memory would fail to be released.
> I've tried to simplify my httpd.conf file to reduce the test case:
>   ServerRoot c:/varju/webct/webct/server
>   ThreadsPerChild 16
>   LoadModule cgi_module modules/
>   LoadModule alias_module modules/
>   Listen 80
>   ScriptAlias / c:/varju/webct/webct/webct/generic/public/
> Can anybody offer me suggestions of where to look next?
> Thanks,
> Alex.

View raw message