web server leaks memory

[twisted-trac]

	okul reported
Trac ID	trac#377
Type	defect
Created	2003-10-30 16:22:16Z

Attachments:

• memleak_server.py (343 bytes) - added by okul on 2003-10-30 16:22:16Z -
• memleak_server2.py (677 bytes) - added by okul on 2003-11-26 19:03:21Z -

Searchable metadata

``` trac-id__377 377 type__defect defect reporter__okul okul priority__high high milestone__ branch__ branch_author__ status__closed closed resolution__fixed fixed component__web web keywords__ time__1067530936000000 1067530936000000 changetime__1078711749000000 1078711749000000 version__ owner__ cc__glyph cc__spiv cc__itamarst cc__okul ```

[twisted-trac]

	Automation removed owner

[twisted-trac]

	okul commented

#!html
<pre>
it seems like first example do not beat ~20Mb limit. i rewrote this little test
to use threads and tried to measure it on 2.4GHz P4, 256MB RAM. there is random
shots during 2days long test with 2 parallel client programs:

VSIZE  RSS COMM
30076 7504 twistd2.2
29468 7024 twistd2.2
...
29940 6940 twistd2.2
...
35592 12212 twistd2.2

gc.garbage is always empty,
</pre>

[twisted-trac]

	okul commented

#!html
<pre>
i started this server with "twistd2.2 --nodaemon --no_save --python
memleak_server.py" and tested with endless loop of
xmlrpclib.ServerProxy("http://localhost:2084/").test()

i dont't know, how to measure python memory usage. i used program top and when i
made 10 request per second, twistd2.2 process memory usage increases about 1 KB
per 10 request.

platform: debian woody, twisted 1.1.0, python 2.2
</pre>

[twisted-trac]

	spiv commented

#!html
<pre>
I can't reproduce this with current CVS (which should be practically the same as
1.1.0, I think).  I'm using debian sid, python 2.2 and python 2.3.

I've also tried periodically dumping ref counts of all the classes while running
this example, and nothing's going up.  The highest count is 66, for &lt;class
'twisted.python.components.MetaInterface'>.

The memory use under 2.3 very quickly reaches and stays at 11140 kB virtual,
7552 kB resident for me.  Under 2.2 the numbers are 8512/6512, but the behaviour
is the same.
</pre>

[twisted-trac]

	@itamarst commented

#!html
<pre>
Glyph and I had this terrible bug where it turned out GC wasn't collecting
objects because they were in wrong generation - gc.collect() did collect them.
That is to say, they would get collected, but it'd take a lot of time.

Thinks which would help us debug (if there is a problem) - tell us the contents
of gc.garbage - it'll be a list of the uncollectable objects that are leaking.
If you don't see anything there, I suggest just doing gc.collect() manually
every 10 seconds.
</pre>

[twisted-trac]

	@jyknight commented

#!html
<pre>
Unreproducible => resolved.
</pre>