#2913: Memory Leak on SVN Repo Access using tracd or WSGI
---------------------------------------+------------------------------------
Reporter: edsuom | Owner: jonas
Type: defect | Status: new
Priority: high | Milestone: 0.10
Component: browser | Version: devel
Severity: major | Resolution:
Keywords: wsgi, tracd, memory, leak |
---------------------------------------+------------------------------------
Changes (by edsuom):
* milestone: => 0.10
* cc: => [EMAIL PROTECTED]
Comment:
I am pleased to announce that the patch ''cached-pool.diff'' fixes the
problem of this ticket by modifying
source:trunk/trac/versioncontrol/svn_fs.py to cache instances of
{{{versioncontrol.svn_fs.Pool}}}. With the patch, RAM usage increases with
subsequent reloads of a given page via the SVN browser, but the RAM will
be released when the browser goes somewhere else instead of being
allocated forever and forming a memory leak. Instead of having RAM usage
climb quickly past 100MB+ from modest SVN repo access, it seems to stay at
around 30-45 MB regardless of whether the HTTP server is run via WSGI or
the standalone ''tracd''.
When an instance of {{{versioncontrol.svn_fs.Pool}}} is constructed for
the first time with a given ''path'' and ''parent pool'' (supplied as
keywords), it creates a new SVN memory pool and cache it in a class-wide
dictionary that is keyed by up to two keywords, a path and the SVN pool
object of the pool's own parent. On subsequent instantiations with the
same combination of keywords, the {{{Pool}}} constructor retrieves the SVN
memory pool from cache and use it if it's still valid, instead of
constructing a new pool afresh.
Validating cache entries is a bit tricky. If a cached pool is itself
valid, the {{{cacheAccess}}} method tries to explores the pool's ancestry
all the way to the top level {{None}}} parent pool object. The exploration
loop will break if any invalid pool is found along the way. So if the
exploration completes, all parents to the cached pool must be valid. In
that case, that {{{Pool()._pool}}} attribute is assigned to the cached
pool and the exploration loop terminates successfully.
I look forward to seeing this committed to trunk soon! I hereby license it
for such inclusion under the same terms as Trac itself.
''Edwin A. Suominen''
--
Ticket URL: <http://projects.edgewall.com/trac/ticket/2913>
The Trac Project <http://trac.edgewall.com/>
_______________________________________________
Trac-Tickets mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-tickets
