Winston, Hudson is a very important part of our infrastructure. If you've found a plugin (or a specific build job) that is obviously leaking memory (thus making our Hudson instance slow) I suggest we disable that plugin and/or job immediately and open a bug to request it be fixed.
In this case, is the problem with a specific plugin, or is it within the job? I can't tell from the words that are written below. Thanks, Denis On 02/22/2012 11:37 AM, Winston Prakash wrote: > Jason, > > I saw your TODO note in the code about the reference. I'm not worried > about that. I'm wondering about the amount of memory it takes to keep > the parsed artifacts info. Only builds of this job takes this much > memory. Could this be because of maven-Javadoc-plugin as mentioned by > Mickael. > > When it comes to memory leak, Stapler and XStream are the worst > enemies I have to fight with :-) > > - Winston > > On 2/21/12 9:08 PM, Jason Dillon wrote: >> IIRC the build state is only in a soft ref when loading from disk, >> but there is a hard-ref when a new build is run, so its retained >> until the server reboots. The project work at sonatype was terminated >> before this and many other issues could be resolved. There needed to >> be some additional api added to the xref bits to allow a reference to >> build state once built to be transitioned from a hard to soft ref. >> >> --jason >> >> >> On Tuesday, February 21, 2012 at 8:51 PM, Winston Prakash wrote: >> >>> Hi Jason D./Stewart, >>> >>> As per request from Eclipse foundation, I'm analyzing performance of >>> their Hudson instance. I noticed that tycho-gmp.gmf.tooling >>> (https://hudson.eclipse.org/hudson/view/Tycho%20+%20Maven/job/tycho-gmp.gmf.tooling) >>> builds are occupying about 120 MB of memory. What is special about >>> this job. The memory is specifically consumed by maven3 plugin data >>> model. When I try to look at the maven3 structure UI >>> (https://hudson.eclipse.org/hudson/view/Tycho%20+%20Maven/job/tycho-gmp.gmf.tooling/136/maven/?) >>> in Hudson it spins for ever. See the tree in the attached image. Any >>> idea what is causing this huge memory consumption? BTW, only builds >>> of this job seem to occupying this much memory. Other job builds >>> consume much less memory (< 10 MB). >>> >>> A memory leak in Stapler causes GC from collecting these huge build >>> related objects and eventually Hudson dies running out of memory. >>> >>> - Winston >>> >>> >>> >> _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
