Re: java process consumes up to 200% CPU while using the UI
There's also the jstack tool which comes which each JDK which can take a stack trace of Jenkins. That might also help to figure out the original problem. Am 11.04.2015 um 17:23 schrieb Brian J. Murrell: On Fri, 2015-04-10 at 11:31 -0400, Brent Atkinson wrote: You're right, but connecting locally should not require the remote ports bound, No. You are right about that. But the problem is that the complaint is not isolated to the JMX report options. *Any* JMX option yields a complaint about duplicate options being found. Anyone know why this doesn't work out-of-the-box? Yes, indeed. Anyone at all? Please. At this point, you have options: * figure out how to enable remote JMX (why it's failing for you) * figure out how to enable local JMX (not sure what's involved) Right. These seem like the most fruitful paths but not really knowing anything at all about how Java applications are developed or deployed (i.e. I have no clue what a Jar is or what Winstone is, etc.) I'm kind of grasping in the dark here. * go another route, such as the monitoring plugin (can't vouch for it) I suspect analysing it from outside (i.e. jconsole) will be more fruitful that analysing from the inside. I did manage to find out that performance is better, (but still not what I would expect) with one of the following plugins disabled: antisamy-markup-formatter.jpi.disabled ant.jpi.disabled cobertura.jpi.disabled configurationslicing.jpi.disabled credentials.jpi.disabled cvs.jpi.disabled external-monitor-job.jpi.disabled git.jpi.disabled javadoc.jpi.disabled locks-and-latches.jpi.disabled mapdb-api.jpi.disabled scm-api.jpi.disabled ssh-slaves.jpi.disabled subversion.jpi.disabled throttle-concurrents.jpi.disabled translation.jpi.disabled windows-slaves.jpi.disabled xunit.jpi.disabled xvnc.jpi.disabled But brute-force is not really the most fruitful way to go about this, particularly when disabling random plugins can actually prevent Jenkins from starting up -- leading to a yak-shaving exercise in debugging plugin dependencies. Plus the fact that even with every single plugin we have installed disabled, performance is still sluggish, just not as sluggish as with one or more of the above plugins enabled. With one or more of the above plugins enabled, job->configure is particularly slow. In any case, maybe time for a new thread on this list about how to enable JMX with Jenkins... Cheers, b. -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/552A34ED.6050207%40gmx.de. For more options, visit https://groups.google.com/d/optout.
Re: java process consumes up to 200% CPU while using the UI
On Fri, 2015-04-10 at 11:31 -0400, Brent Atkinson wrote: > > You're right, but connecting locally should not require the remote ports > bound, No. You are right about that. But the problem is that the complaint is not isolated to the JMX report options. *Any* JMX option yields a complaint about duplicate options being found. > Anyone know why this doesn't work > out-of-the-box? Yes, indeed. Anyone at all? Please. > At this point, you have options: > > * figure out how to enable remote JMX (why it's failing for you) > * figure out how to enable local JMX (not sure what's involved) Right. These seem like the most fruitful paths but not really knowing anything at all about how Java applications are developed or deployed (i.e. I have no clue what a Jar is or what Winstone is, etc.) I'm kind of grasping in the dark here. > * go another route, such as the monitoring plugin (can't vouch for it) I suspect analysing it from outside (i.e. jconsole) will be more fruitful that analysing from the inside. I did manage to find out that performance is better, (but still not what I would expect) with one of the following plugins disabled: antisamy-markup-formatter.jpi.disabled ant.jpi.disabled cobertura.jpi.disabled configurationslicing.jpi.disabled credentials.jpi.disabled cvs.jpi.disabled external-monitor-job.jpi.disabled git.jpi.disabled javadoc.jpi.disabled locks-and-latches.jpi.disabled mapdb-api.jpi.disabled scm-api.jpi.disabled ssh-slaves.jpi.disabled subversion.jpi.disabled throttle-concurrents.jpi.disabled translation.jpi.disabled windows-slaves.jpi.disabled xunit.jpi.disabled xvnc.jpi.disabled But brute-force is not really the most fruitful way to go about this, particularly when disabling random plugins can actually prevent Jenkins from starting up -- leading to a yak-shaving exercise in debugging plugin dependencies. Plus the fact that even with every single plugin we have installed disabled, performance is still sluggish, just not as sluggish as with one or more of the above plugins enabled. With one or more of the above plugins enabled, job->configure is particularly slow. In any case, maybe time for a new thread on this list about how to enable JMX with Jenkins... Cheers, b. -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/1428765798.17324.6.camel%40interlinx.bc.ca. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part
