-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Windows Server 2008 R2 , x86/32 (1 cores)
Java(TM) SE Runtime Environment, 1.6.0_26-b03
Our Jenkins master handles just under 300 jobs with about half using SCM (subversion) polling. After a major branching event, we updated to version 1.481 of Jenkins and 1.42 of the subversion plugin. We saw extremely high memory usage shortly after startup with noticeably degraded performance. Analyzing a heap dump with eclipse mat, we got the following summary:
One instance of "java.util.TaskQueue" loaded by "<system class loader>" occupies 792,697,824 (73.68%) bytes. The instance is referenced by org.tmatesoft.svn.core.wc.DefaultSVNRepositoryPool @ 0x3267810 , loaded by "java.net.URLClassLoader @ 0x1ce7c938". The memory is accumulated in one instance of "java.util.TimerTask[]" loaded by "<system class loader>".
After rolling back our subversion plugin to 1.39, with no other changes to our configuration, memory usage settled back into a much more nominal (for us) range.
- duplicates
-
JENKINS-13854 Subversion plugin polling memory leak
-
- Open
-
Same problem here with Jenkins version 1.492 (except we do not experience performance issues right now). I compared two heap dumps. One taken yesterday and one from today and the total retained size of the "java.util.TaskQueue" instance grew from ~900MB to ~1.3GB (second value is more than 50% of overall heap).
I also compared those recent dumps with some older ones from a Jenkins with version 1.471. There were just 1 or 2 instances of DefaultSVNRepositoryPool held by TaskQueue compared to the >36000 instances in the newer snapshots.
In both versions we used Subversion plugin 1.43. We recently upgraded Jenkins and some plugins (including http://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin). So this probably could be a problem of this plugin too. But since I haven't had time to analyze it further, this is just speculation.