Possible memory leak (after moving away from 5898)

[ilias@…]

At some point after moving away from r5898, a memory leak occoured. I cannot recreate when this happened exactly.

One other updated-point was the r6323.

The current constellation (apache mod_python):

System Information
Trac: 	0.11b1
Python: 	2.4 (#1, Mar 22 2005, 21:42:42) [GCC 3.3.5 20050117 (prerelease) (SUSE Linux)]
setuptools: 	0.6c7
SQLite: 	3.3.4
pysqlite: 	2.1.3
Genshi: 	0.5dev-r786
Pygments: 	0.7.1
Subversion: 	1.1.3 (r12730)
jQuery:	1.2.1
I've currently updated to the 0.11dev version. 

I've looked a little at trac:#6437, trac:#5167, genshi:#166

Note that I had a similar issue (#4885), which was not a leak but a higher memory usage of the new trac version. But this time it looks that there's really a memory-leak.

[ilias@…]

After restart

s15211113:~ # ps -e -o vsize,size,rss,cmd | grep httpd
 39840  7712 17368 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 15944  5564  4924 /usr/sbin/fcgi-pm        -f /etc/apache2/httpd.conf
 62204 28208 34956 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 55312 21316 28328 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 52472 18476 25560 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 51796 17800 24496 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 51792 17796 24516 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 51864 17868 24560 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 51736 17740 24828 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 51776 17780 24380 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf

few minutes later:

 # ps -e -o vsize,size,rss,cmd | grep httpd
 39840  7712 17368 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 15944  5564  4924 /usr/sbin/fcgi-pm        -f /etc/apache2/httpd.conf
 92920 58924 66188 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 84636 50640 57880 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 77404 43408 51112 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
103688 69692 76788 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 88924 54928 62484 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 89884 55888 62984 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 93676 59680 67156 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 85000 51004 58200 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 77856 43860 51096 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 89096 55100 62236 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf

(will post another one when it's close before limit)

[ilias@…]

now at 94% of resources, close to collapse

# ps -e -o vsize,size,rss,cmd | grep httpd
 39840  7712 17380 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 15944  5564  4924 /usr/sbin/fcgi-pm        -f /etc/apache2/httpd.conf
110440 76444 84028 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
113792 79772 87280 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
120772 86776 93356 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
120208 86212 93444 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
113472 79476 86740 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
118020 84024 91140 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
113440 79444 86792 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
112980 78984 86360 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
104644 70648 77916 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
 93976 59980 66656 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf

[nkantrowitz]

Python 2.4 is known to have several major memory issues. To get accurate information you will need to use at least 2.5.

[ilias@…]

Replying to nkantrowitz:

Python 2.4 is known to have several major memory issues. To get accurate information you will need to use at least 2.5.

wasn't aware of this. I cannot switch to 2.5 at this point, but I'm just activating an Dedicated Server (Suse 10.1, again with python 2.4) to see if I have the same memory problems as with the Virtual Private Server.

[ilias@…]

I am now on Suse 10.2 with python 2.5 on a dedicated machine, an it seems that the memory problems still exists (will report more those days).

ps -e -o vsize,size,rss,cmd | grep httpd
317936 19548 14600 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
507140 111768 98944 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
516024 113760 102172 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
510588 115216 102340 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
501224 105852 93880 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
491824 96452 84956 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
496664 101292 90188 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
480964 85592 73688 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
497744 95480 84748 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
486448 91076 80028 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
488716 93344 81880 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf
  4100   252   568 grep httpd
317936 19548 23580 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf

[osimons]

Could you also test with latest Genshi trunk without the C extension? To disable it, install genshi with optional argument: python setup.py install --without-speedups

Are the results comparable?

(BTW: I haven't looked into this at all myself - it is just a tip for testing.)

[ilias@…]

Replying to osimons:

Could you also test with latest Genshi trunk without the C extension? To disable it, install genshi with optional argument: python setup.py install --without-speedups

I've installed: python setup.py --without-speedups develop

how can I ensure that the C extension is not active (e.g. remained active from older installation etc.).

[ilias@…]

Is there any piece of code which I can use to produce more precise numbers about memory usage?

I've seen this here within genshi:#166

is the code applicable to any memory problem?

[ilias@…]

memory usage is quite high on the dedicated server, but it does not hit the limit.

so, it worksforme now, but only after moving away from the old VPS box. Possibly, just the memory consumptions has increased again.