Details
-
Bug
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Fixed
-
Master:
openjdk version "1.8.0_66-internal"
OpenJDK Runtime Environment (build 1.8.0_66-internal-b01)
OpenJDK 64-Bit Server VM (build 25.66-b01, mixed mode)
Slaves:
java version "1.7.0_111"
OpenJDK Runtime Environment (IcedTea 2.6.7) (7u111-2.6.7-0ubuntu0.14.04.3)
OpenJDK 64-Bit Server VM (build 24.111-b01, mixed mode)
Master: openjdk version "1.8.0_66-internal" OpenJDK Runtime Environment (build 1.8.0_66-internal-b01) OpenJDK 64-Bit Server VM (build 25.66-b01, mixed mode) Slaves: java version "1.7.0_111" OpenJDK Runtime Environment (IcedTea 2.6.7) (7u111-2.6.7-0ubuntu0.14.04.3) OpenJDK 64-Bit Server VM (build 24.111-b01, mixed mode)
Description
When sending a stash across the network, the data transfer can be significantly slower than the underlying network. This seems to be due to some slow on-the-fly compression happening during the transfer. Using the following script, the Unstash phase takes 1-2 seconds for 10MB of /dev/zero, and 49 seconds for 10MB of /dev/urandom. The Stash phase consistently takes 1-2 seconds. This makes me think there's a compression step, since /dev/zero should compress much faster than /dev/urandom.
node {
deleteDir()
stage "Stash"
sh "dd if=/dev/zero of=data bs=1M count=10"
stash name: 'build_outputs', includes: 'data'
sh "date"
node('lab') {
deleteDir()
stage "Unstash"
unstash 'build_outputs'
sh "ls -al"
}
}
This looks similar to JENKINS-36914, in particular this comment:
https://issues.jenkins-ci.org/browse/JENKINS-36914?focusedCommentId=268472&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-268472
I'm not calling this a dupe of that because the original text refers to stash only, and this bug seems isolated to unstash. Also this is on x86, not ARM.
Attachments
Issue Links
- is duplicated by
-
-
- Closed
-
- is related to
-
-
- Resolved
-
- links to
Activity
There is NO official recommendation to avoid stash/unstash. I've just mentioned it as a possible workaround
John Koleszar
added a comment - Thanks, Oleg. This is the documentation I was referring to about stash only being suitable for small files:
https://github.com/jenkinsci/workflow-basic-steps-plugin/commit/413df48bdcb832261e8fb110150eeb8069e77c33
Maybe there's an upper limit where it falls over, but I haven't hit it yet. In my opinion, if there were one, it'd be a bug worth fixing, rather than something to document away as WAI.
John Koleszar
added a comment - Thanks, Oleg. This is the documentation I was referring to about stash only being suitable for small files:
https://github.com/jenkinsci/workflow-basic-steps-plugin/commit/413df48bdcb832261e8fb110150eeb8069e77c33
Maybe there's an upper limit where it falls over, but I haven't hit it yet. In my opinion, if there were one, it'd be a bug worth fixing, rather than something to document away as WAI. This ticket is quite old but in the past lots of changes have happened and I wonder what the current network usage with stashing is. Did the Jenkins guys improve stashing?
My background is that the CI builds various C++ testsuites and I would like to split up building and testing. That's where stashing would be useful if the performance of copying the involved files would be acceptable. In the past this has been really bad - with or without compression enabled.
Any current experiences?
I'm talking about folders to be copied with e.g. 500MB.
The admonition not to use stash is too strong, in my opinion. I can see plenty of situations where having a repository manager or setting up shared storage are completely unnecessary complexity. The latest release of this plugin performs as I'd expect.