Cobertura plugin (that can have huge report data to store in memory) uses a
WeakReference to avoid OOME, but generally speaking all build data indeed
increase memory footprint. Many widget (trends) need access to build
history data, so some lazy-loading strategy should not help here. Best
practice or new design considerations are welcome

2012/9/10 Mark Waite <[email protected]>

> I believe that is intentional.  The technique I've commonly used is to use
> the Jenkins setting to trim the history of jobs to a smaller set (in my
> case, a week's worth or less).
>
> If you have a use case which requires that you keep so long a history, you
> will probably find that Jenkins starts more and more slowly as your history
> grows.
>
> Mark Waite
>
>   ------------------------------
> *From:* bearrito <[email protected]>
> *To:* [email protected]
> *Cc:* [email protected]
> *Sent:* Monday, September 10, 2012 11:08 AM
> *Subject:* Re: Is every build kept in the JVM?
>
> I wonder if that is intentional or a memory leak.
>
> Great to know this by the way. Does it load all the metadata on service
> startup or does it slowly accumulate?
>
> -barrett
>
> On Monday, September 10, 2012 8:58:44 AM UTC-4, Mandeville, Rob wrote:
>
>  I’m getting OOM exceptions left and right in my Jenkins instance.  It’s
> a fairly large installation, with over 100 slave nodes, and I’m running in
> Java 6 HotSpot.  I generated a heap dump (great feature to do that via the
> Web page, BTW) and finding something that was surprising to me.
>
> It appears that every build that Jenkins “remembers” is kept in the JVM
> itself.  That is, when I’m keeping the last 400 runs of a given job, I have
> the metadata (though not the logs, I hope…) of all 400 runs in the JVM.  Is
> this in fact the case?  Is there a way to store build information
> historically without keeping it in core?  Is this a problem for other users?
>
> Thanks in advance,
>
> --Rob
>
>  The information in this message is for the intended recipient(s) only
> and may be the proprietary and/or confidential property of Litle & Co.,
> LLC, and thus protected from disclosure. If you are not the intended
> recipient(s), or an employee or agent responsible for delivering this
> message to the intended recipient, you are hereby notified that any use,
> dissemination, distribution or copying of this communication is prohibited.
> If you have received this communication in error, please notify Litle & Co.
> immediately by replying to this message and then promptly deleting it and
> your reply permanently from your computer.
>
>
>
>

Reply via email to