Agreed - I think this is one thing that, if fixed/redesigned, would be a big help! Having said that I'm guessing from all the comments that it would mean a pretty big effort?
Richard. On Tue, Sep 11, 2012 at 6:00 AM, Christoph Kutzinski <ku...@gmx.de> wrote: > I'd say it's intentionally AND a memory leak ;-) > This is IMO one of the major pain points with Jenkins. We keep 'only' 3 > weeks worth of builds and still it takes >40 minutes for a Jenkins startup - > spending the majority of the time in loading the builds. > > > Unfortunately, it doesn't seem to be easy to fix this without breaking > existing API. I had once tried to figure out an easy way to load old builds > only on demand, but gave up after several hours. > > As Mark already said, the currently preferred solution is to remove old > builds. > > > Christoph > > Am 10.09.2012 19:08, schrieb bearrito: > >> 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. >> >
