Skip to main content

[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


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.



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
>>> (
>>> 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
>>> (
>>> 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

Back to the top