We're running Jenkins master with a bunch of slaves. Typical load on the
master is around 5-10% which is not very much. Several times now, we've
gotten into spikes where the CPU goes to 100% and stays there until we
restart it, and this usually only helps a little.

  We dump the stack, and typically we find a whole bunch of threads sitting
there marshaling XML aggressively. Usually, we can connect this to a plugin
via the stack trace, and we'll uninstall that plugin, and that tends to

  So far, the plugins I can remember include:

* audit-trail
* build-timer
* log-parser

  That's just the most recent ones that I can remember. We must be going on
the 5th or 6th plugin now. I'm afraid it's starting to shake peoples
confidence in Jenkins, I'd rather not have to replace it with a different
build system because it generally works, but when it doesn't - it's bad. We
actually keep a CircleCI system around because we haven't been able to
build enough confidence in Jenkins.

  I have a couple general questions:

  1) We're on Jenkins 2.18 - so, why does this keep happening? We've seen
other bugs about threads getting stuck hammering the CPU. Seems like the
issues were marked as resolved, but we end up having to uninstall these
plugins all together.

  2) Is there a list of known "bad" plugins?

  3) Why not cache more and guard against this? It's easy to blame the
plugins as the thing triggering this, but why not make Jenkins core more
resilient to this, and assume people can't/won't write perfect plugins?
Getting to be a fool me once type of situation here....

- Eric

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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to