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
