Memory Leak on SVN Repo Access using tracd or WSGI
|Reported by:||edsuom||Owned by:||Jonas Borgström|
|Severity:||major||Keywords:||wsgi, tracd, memory, leak|
A memory leak is apparent in the trac SVN browser when it is accessed via tracd or WSGI , both of which methods leave the Python interpreter running between web requests. Every time a source file page from SVN is loaded via your web browser, memory usage goes up by over 1 MB. I did some snooping on the Python classes with the most refcounts and noted the following new, non-garbage-collected class instances added with every reload of a source file from SVN with the trac browser:
- Four of the following:
- Two of each of the following:
libsvn.core.apr_pool_t libsvn.repos.svn_repos_tPtr libsvn.fs.svn_fs_root_tPtr libsvn.fs.svn_fs_tPtr
- One of each of the following:
libsvn.repos.svn_repos_t libsvn.fs.svn_fs_root_t libsvn.fs.svn_fs_t
Then I did some further snooping with logging statements inserted into
source:root/trunk/trac/versioncontrol/svn_fs.py. That revealed that every
source file reload from the SVN browser instantiates
trac.versioncontrol.svn_fs.Pool twice. One of the two instances is the
self._parent_pool for the other.
This is a pretty serious problem for anyone wanting to run a robust trac site via WSGI or by reverse proxying to tracd. Indeed, I heard the comment on IRC that tracd is a memory hog, and I imagine this issue is exactly the reason for that perception.