Hi, I am not sure if this issue is resolved or not, but getting the same in my jenkins server.
I am running the version 1.505 and it is a standalone server. Here is my thread dump.

"JmDNS(fe80:0:0:0:223:7dff:fe57:9ade%2.local.).State.Timer" prio=10 tid=0x10cd6000 nid=0x76bc in Object.wait() [0x0efeb000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.util.TimerThread.mainLoop(Timer.java:509)

• locked <0x3e5e30c8> (a java.util.TaskQueue)
  at java.util.TimerThread.run(Timer.java:462)

"JmDNS(fe80:0:0:0:223:7dff:fe57:9ade%2.local.).Timer" daemon prio=10 tid=0x10cd4c00 nid=0x76bb in Object.wait() [0x0f03d000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.util.TimerThread.mainLoop(Timer.java:509)

• locked <0x3e5e8498> (a java.util.TaskQueue)
  at java.util.TimerThread.run(Timer.java:462)

"SocketListener(fe80:0:0:0:223:7dff:fe57:9ade%2.local.)" daemon prio=10 tid=0x10a46000 nid=0x76ba runnable [0x0f08d000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainDatagramSocketImpl.receive0(Native Method)

• locked <0x3e5e34c8> (a java.net.PlainDatagramSocketImpl)
  at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
• locked <0x3e5e34c8> (a java.net.PlainDatagramSocketImpl)
  at java.net.DatagramSocket.receive(DatagramSocket.java:712)
• locked <0x3e688c50> (a java.net.DatagramPacket)
• locked <0x3e5e3498> (a java.net.MulticastSocket)
  at javax.jmdns.impl.SocketListener.run(SocketListener.java:41)

"Thread-19" daemon prio=10 tid=0x10a43800 nid=0x76b9 runnable [0x0f0de000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.fill_buffer(CipherInputStream.java:41)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.internal_read(CipherInputStream.java:52)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.getBlock(CipherInputStream.java:79)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.read(CipherInputStream.java:108)
at com.trilead.ssh2.transport.TransportConnection.receiveMessage(TransportConnection.java:232)
at com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:677)
at com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:475)
at java.lang.Thread.run(Thread.java:619)

"Thread-17" daemon prio=10 tid=0x091bec00 nid=0x76b8 runnable [0x0f12f000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.fill_buffer(CipherInputStream.java:41)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.internal_read(CipherInputStream.java:52)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.getBlock(CipherInputStream.java:79)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.read(CipherInputStream.java:108)
at com.trilead.ssh2.transport.TransportConnection.receiveMessage(TransportConnection.java:232)
at com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:677)
at com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:475)
at java.lang.Thread.run(Thread.java:619)

"Thread-8" daemon prio=10 tid=0x091be800 nid=0x76b7 runnable [0x0f189000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.fill_buffer(CipherInputStream.java:41)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.internal_read(CipherInputStream.java:52)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.getBlock(CipherInputStream.java:79)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.read(CipherInputStream.java:108)
at com.trilead.ssh2.transport.TransportConnection.receiveMessage(TransportConnection.java:232)
at com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:677)
at com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:475)
at java.lang.Thread.run(Thread.java:619)

"Thread-18" daemon prio=10 tid=0x082ca400 nid=0x76b6 runnable [0x0f1da000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.fill_buffer(CipherInputStream.java:41)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.internal_read(CipherInputStream.java:52)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.getBlock(CipherInputStream.java:79)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.read(CipherInputStream.java:108)
at com.trilead.ssh2.transport.TransportConnection.receiveMessage(TransportConnection.java:232)
at com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:677)
at com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:475)
at java.lang.Thread.run(Thread.java:619)

"Thread-16" daemon prio=10 tid=0x091bc800 nid=0x76b5 runnable [0x0f22b000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.fill_buffer(CipherInputStream.java:41)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.internal_read(CipherInputStream.java:52)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.getBlock(CipherInputStream.java:79)
at com.trilead.ssh2.crypto.cipher.CipherInputStream.read(CipherInputStream.java:108)
at com.trilead.ssh2.transport.TransportConnection.receiveMessage(TransportConnection.java:232)
at com.trilead.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:677)
at com.trilead.ssh2.transport.TransportManager$1.run(TransportManager.java:475)
at java.lang.Thread.run(Thread.java:619)

Can someone advise me on how to overcome this issue of slowness in jenkins?

Thanks.

I too have been experiencing similar problems with the Jenkins dashboard. I'm using the latest release as of last week (1.513). The problem seems to arise once a build / job has begun. Navigating the dashboard otherwise seems fine, but when a build kicks in it can take minutes for the dashboard to respond. Even just running a single job with minimal load on the system (e.g.: < 10% CPU usage) the dashboard becomes unusable, even on a high-end development machine (e.g.: Win7 x64, i7 3.4Ghz, 16GB RAM, SSD, etc.)

Now I have been unable to find any log files in the Jenkins home folder that include the level of detail others are reporting above. Perhaps I need to increase the verbosity level somewhere in the Jenkins configuration. If anyone could suggest where to look for that I'd appreciate it.

NOTE: Given that several comments earlier in this thread suggest that this problem may be related to one or more plugins not working correctly, I decided to disable all non-essential plugins from my test instance, leaving just one or two key plugins like the one for SVN SCM, and the dashboard seems to become responsive again. This suggests there may be something to this. I'll have to do some further ad-hoc testing to try and isolate this to a particular plugin, but there does seem - at first glance anyway - that there is a relation between the dashboard performance and one or more plugins.

Update
I just modified the configuration of my master slightly as follows:

• added an agent process to run on the same machine as the master dashboard
• redirected all builds previously managed by the master to the new agent

And so far this seems to have alleviated the slow dashboard problem. Everything else remained unchanged in my configuration. All of the same builds previously running on the local machine are still running there, so the overall load on the system is consistent. The same version of Jenkins, with all the same plugins (and versions of those plugins) remain. etc.

This seems to suggest that there may be some kind of threading problem with the main Jenkins dashboard where if too may child threads are spawned for concurrently running builds something (Jenkins, the JVM, etc.) runs out of resources or something and thus the web dashboard gets blocked until sufficient resources (ie: threads) become available.

Hi Kevin,

To be clear, are you saying that you have the master application running, but you added a service/agent on the master server to act as a separate slave, and then adjusted all of the jobs to point to that "slave" and that seemed to fix your problem?

Yes - this is correct. Everything else was kept consistent on the configuration during this change. The addition of a separate agent process on the same PC as the Jenkins master service to manage the job threads seems to have fixed the problem.

AbstractStatusesColumn.getLastUnstableBuild as currently written is not suitable for use on Jenkins 1.485+. You must never attempt to iterate all builds in a job unless this is truly crucial for correctness and you are not running in an HTTP rendering thread. In some cases it makes sense to do a limited search, say going back ten or twenty builds at the most. However this is silly because there is already a Job.getLastUnstableBuild which is designed to operate efficiently (at least as of JENKINS-16023).

Assigning to the Compact Columns plugin. There may well be similar bugs in other plugins but they would better be filed separately.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/com/robestone/hudson/compactcolumns/AbstractStatusesColumn.java
http://jenkins-ci.org/commit/compact-columns-plugin/40af81d203ac0a3dd8cbeefe0f544fd1edc583d5
Log:
[FIXED JENKINS-15601] Use Job.getLastUnstableBuild, which is safe for 1.485+.
Also in getLastAbortedBuild, limit the number of builds searched.

Compare: https://github.com/jenkinsci/compact-columns-plugin/compare/15dff22c9bd3...40af81d203ac

Awesome! I saw this update and thought, "maybe this is what is causing our views to load so slowly," and applied the update and lo and behold!

Thanks for the fix!