Awesome, thanks so much. That's very good information. I really appreciate the response! Thanks everyone!
On Thursday, January 8, 2015 4:00:36 AM UTC-5, James Nord wrote: > > its not really per job - connections to the http(s) interface also use > file descriptors so you need to factor in how many clients you will have > connecting and if they use persistent connections and the slaves and type > of slaves, how many plugins you have installed - which version of the JDK > you have and how its tuned (storing the compiled machine code). The upper > burst limit may also depend on what your job does and what type it is - > e.g. archiving files will create some FDs whilst the file is being copied > across (they should be closed afterwards). > > I used 10k for several thousand jobs with a few hundred users. I was > monitoring it for a while (several years ago) and it did stabalize - I > can't recall the exact number. > > That's not to say there isn't a leak somewhere - but if you up the limit > and track it with 'lsof' over a period of days/weeks I think you may see > that it is relativley stable, if not you should at least see a common trend > of something that is constantly increasing. (a combination of awk sort and > uniq should be able to show any upward trends - if you have an executor on > the same OS as the master you could also do this through jenkins and use > the plot plugin to visualize :-) > > /James > > > > > > On 07/01/2015 22:05, Sean Last wrote: > > Ok, i'll up the limit, but is there any metric I can use for what's > reasonable versus what's worrisome in an average case/per job? > > On Wednesday, January 7, 2015 5:00:55 PM UTC-5, James Nord wrote: >> >> The default max file handles in most Linux installs (1024) for Jenkins is >> woefully inadequate. >> >> Java itself will have many open files to libs and jars, jenkins will then >> have the for jobs, users and slaves. >> >> I recall also that the lib used by the fd plugin doesn't count all for >> descriptors and I think I submitted a patch. It certainly will only get >> descriptors opened after it is hooked up which is after java itself has got >> may handles which can give you a significant difference. >> >> I would up the limit and then run a periodic check on the file handles to >> check that there are no leaks over time. >> >> On 7 January 2015 20:21:50 GMT+00:00, Sean Last <[email protected]> >> wrote: >>> >>> Yes, restarting jenkins completely clears the open files for the jenkins >>> user, even though the jenkins application is unaware of the open files. >>> >>> On Wednesday, January 7, 2015 3:06:39 PM UTC-5, LesMikesell wrote: >>>> >>>> On Wed, Jan 7, 2015 at 1:55 PM, Sean Last <[email protected]> wrote: >>>> > And I know I could just up the open files limit for the jenkins user, >>>> but >>>> > I'd really like to know why this is happening so it doesn't just keep >>>> > growing until it's full regardless of where I put the limit. >>>> >>>> Off the top of my head, a bug in the JVM you are using sounds likely. >>>> Have you tried different versions or checked its issues? And does a >>>> jenkins restart drop the number significantly compared to after >>>> running a long time? >>>> >>>> -- >>>> Les Mikesell >>>> [email protected] >>>> >>> > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/0b37a44a-c40f-47e9-9565-1258e46cf425%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
