[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] tycho-gmp.gmf.tooling builds consumes enormous amount of memory
|
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
