-
Bug
-
Resolution: Fixed
-
Major
-
Linux master, OSX Slave, Disk Usage 0.23, Jenkins 1.549, Java 6
We use workspace with large number of files, since the last update of the Jenkins Disk Usage plugin our build post processing is taking ages (4 times slower). We notice the slowdown only on OSX slaves.
We suspect this feature in the plugin : Don't follow symlinks
Here the thread dump when the job completed but the slave is still busy with the plugin :
"pool-1-thread-101 for channel" Id=128 Group=main BLOCKED on hudson.remoting.RemoteClassLoader@fda5bfa owned by "pool-1-thread-767 for channel" Id=2764
at java.lang.ClassLoader.loadClass(ClassLoader.java:291)
- blocked on hudson.remoting.RemoteClassLoader@fda5bfa
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at hudson.plugins.disk_usage.DiskUsageUtil.isSymlink(DiskUsageUtil.java:175)
at hudson.plugins.disk_usage.DiskUsageUtil.getFileSize(DiskUsageUtil.java:201)
at hudson.plugins.disk_usage.DiskUsageUtil.getFileSize(DiskUsageUtil.java:201)
at hudson.plugins.disk_usage.DiskUsageUtil.getFileSize(DiskUsageUtil.java:201)
at hudson.plugins.disk_usage.DiskUsageUtil.getFileSize(DiskUsageUtil.java:201)
at hudson.plugins.disk_usage.DiskUsageUtil.getFileSize(DiskUsageUtil.java:201)
at hudson.plugins.disk_usage.DiskUsageUtil.getFileSize(DiskUsageUtil.java:201)
at hudson.plugins.disk_usage.DiskUsageUtil.getFileSize(DiskUsageUtil.java:201)
at hudson.plugins.disk_usage.DiskUsageUtil.getFileSize(DiskUsageUtil.java:201)
at hudson.plugins.disk_usage.DiskUsageUtil.getFileSize(DiskUsageUtil.java:201)
at hudson.plugins.disk_usage.DiskUsageUtil$DiskUsageCallable.call(DiskUsageUtil.java:399)
at hudson.plugins.disk_usage.DiskUsageUtil$DiskUsageCallable.call(DiskUsageUtil.java:380)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:695)
Number of locked synchronizers = 1
- java.util.concurrent.locks.ReentrantLock$NonfairSync@65962a71
Downgrading the plugin to 0.20 fixed our problem
[JENKINS-21718] Jenkins Disk usage slowdown completely jobs since don't follow symlinks
Class<?> files = Thread.currentThread().getContextClassLoader().loadClass( "java.nio.file.Files" ); Class<?> path = Thread.currentThread().getContextClassLoader().loadClass( "java.nio.file.Path" ); Class<?> paths = Thread.currentThread().getContextClassLoader().loadClass( "java.nio.file.Paths" );
is obviously wrong: if these classes exist, they must be in the bootstrap loader, so it is unnecessary and inefficient to check from the context class loader.
Lucie Votypkova
added a comment - Yes you are right. It is my mistake, I wanted to have it for java 6 too, but try to use java.nio.fileFiles first, because jenkins Util.isSymlink() did not support all architectures. I will obtain it better way, thanks.
Lucie Votypkova
added a comment - Yes you are right. It is my mistake, I wanted to have it for java 6 too, but try to use java.nio.fileFiles first, because jenkins Util.isSymlink() did not support all architectures. I will obtain it better way, thanks. Lucie Votypkova
added a comment - fixed in https://github.com/jenkinsci/disk-usage-plugin/commit/b4dd403052c547c9667bc0178afaadda46f80563. Now the method isSymlink does the same (and better) in hudson.Util. Lets fully delegate on it.
Lucie Votypkova
added a comment - fixed in https://github.com/jenkinsci/disk-usage-plugin/commit/b4dd403052c547c9667bc0178afaadda46f80563 . Now the method isSymlink does the same (and better) in hudson.Util. Lets fully delegate on it. 
We are having the same issue. I think the original report has the wrong version - we are using version 0.23 and seeing this as well.
Our master and slaves are running on java 6. It looks like the code checks if a java 7 feature is available using the class loader, which goes over the remoting channel, for every directory.