I'm also having an intermuitant 100% CPU problem.
I found that the Jenkins Monitoring plugin was a big help in identifiying
the offending threads.
In my case, it is casued by looking at an EMMA code coverage report in the
browser.
-Richard
On Thursday, February 7, 2013 9:47:20 AM UTC-8, An
Hi Oliver,
It doesn't appear to have helped. Hitting the asyncPeople link pegs
the CPU and just stalls. FWIW, I'm on the LTS release and have updated
all the plugins to their latest versions.
-Andrew
On Thu, Feb 7, 2013 at 10:46 AM, Andrew Melo wrote:
> On Thu, Feb 7, 2013 at 4:10 AM, oliver go
On Thu, Feb 7, 2013 at 4:10 AM, oliver gondža wrote:
> On Wed, 06 Feb 2013 21:13:42 +0100, Andrew Melo
> wrote:
>
>> Hey everyone,
>>
>> Sorry for resurrecting that thread, but are there any solutions for
>> this problem? It's basically killing our instance often.
>>
>> best,
>> Andrew
>
>
> Hi,
On Wed, 06 Feb 2013 21:13:42 +0100, Andrew Melo
wrote:
Hey everyone,
Sorry for resurrecting that thread, but are there any solutions for
this problem? It's basically killing our instance often.
best,
Andrew
Hi, subversion-plugin in version 1.45 does not longer have
MailAddressResolver i
Hey everyone,
Sorry for resurrecting that thread, but are there any solutions for
this problem? It's basically killing our instance often.
best,
Andrew
On Wed, Aug 1, 2012 at 11:47 AM, Andrew Melo wrote:
> Oh, wow, I didn't notice, but jenkins has autopopulated a user for
> everyone that ever c
Oh, wow, I didn't notice, but jenkins has autopopulated a user for
everyone that ever committed on the project. There's like 30 people,
~4000 commits, so I could see why that would take a while :)
On Wed, Aug 1, 2012 at 11:42 AM, Andrew Melo wrote:
> On Wed, Aug 1, 2012 at 11:37 AM, Slide wrote:
On Wed, Aug 1, 2012 at 11:37 AM, Slide wrote:
> Can you gist your global config.xml and something from one of your
> jobs as well? Please remember to sanitize it.
We actually keep it stored in SCM. https://github.com/dmwm/jenkins/
And the following is the gist for the job we run each commit (did
Can you gist your global config.xml and something from one of your
jobs as well? Please remember to sanitize it.
On Wed, Aug 1, 2012 at 9:34 AM, Andrew Melo wrote:
> On Wed, Aug 1, 2012 at 11:26 AM, Slide wrote:
>> No, because its only looking for the email address because it wants to
>> send an
On Wed, Aug 1, 2012 at 11:26 AM, Slide wrote:
> No, because its only looking for the email address because it wants to
> send an email to that user.
I don't know who's getting emailed. I don't remember setting it up for
anything, and we actually wrote some scripts that turn jenkins
success/failur
No, because its only looking for the email address because it wants to
send an email to that user.
On Wed, Aug 1, 2012 at 9:24 AM, Andrew Melo wrote:
> On Wed, Aug 1, 2012 at 11:22 AM, Slide wrote:
>> This is a huge issue with the email-ext plugin as well when it does
>> email address resolution
On Wed, Aug 1, 2012 at 11:22 AM, Slide wrote:
> This is a huge issue with the email-ext plugin as well when it does
> email address resolution. Quite a number of people have complained
> about how long it takes. I have yet to come up with a good solution.
> The perforce plugin has a similar issue.
On Wed, Aug 1, 2012 at 11:17 AM, Vojtech Juranek wrote:
> Looks like you it does search for user's email:
> hudson.scm.SubversionMailAddressResolverImpl.findMailAddressFor
> and spends time parsing changelogs:
> hudson.scm.SubversionChangeLogParser.parse
>
> I guess you have quite large instance,
This is a huge issue with the email-ext plugin as well when it does
email address resolution. Quite a number of people have complained
about how long it takes. I have yet to come up with a good solution.
The perforce plugin has a similar issue.
slide
On Wed, Aug 1, 2012 at 9:17 AM, Vojtech Jurane
Looks like you it does search for user's email:
hudson.scm.SubversionMailAddressResolverImpl.findMailAddressFor
and spends time parsing changelogs:
hudson.scm.SubversionChangeLogParser.parse
I guess you have quite large instance, otherwise this operation would be quite
fast.
If you have some job,
On Wed, Aug 1, 2012 at 10:36 AM, Vojtech Juranek wrote:
> On Wednesday 01 August 2012 10:07:15 Andrew Melo wrote:
>> On Wed, Aug 1, 2012 at 9:48 AM, Vojtech Juranek wrote:
>> > quick way how to look what the thread consuming CPU is doing is to do
>> > thread dump (e.g. using jstack $PID) and use
On Wednesday 01 August 2012 10:07:15 Andrew Melo wrote:
> On Wed, Aug 1, 2012 at 9:48 AM, Vojtech Juranek wrote:
> > quick way how to look what the thread consuming CPU is doing is to do
> > thread dump (e.g. using jstack $PID) and use top with threads on (H
> > option) and then look up, see e.g.
On Wed, Aug 1, 2012 at 9:48 AM, Vojtech Juranek wrote:
> quick way how to look what the thread consuming CPU is doing is to do thread
> dump (e.g. using jstack $PID) and use top with threads on (H option) and then
> look up, see e.g.
> http://code.nomad-labs.com/2010/11/18/identifying-which-java-t
quick way how to look what the thread consuming CPU is doing is to do thread
dump (e.g. using jstack $PID) and use top with threads on (H option) and then
look up, see e.g.
http://code.nomad-labs.com/2010/11/18/identifying-which-java-thread-is-
consuming-most-cpu/
On Wednesday 01 August 2012 09:
18 matches
Mail list logo
