Open timja opened 8 years ago
I tried increasing -Xmx to 1500m but it still runs out of memory. 2000m does not work because I run 32 bit java. I will try to upgrade to 64 bit java to see if it helps go to 2000m and beyond.
oleg_nenashev Is this a remoting issue?
I can give you a little more information while I run a test on 64 bit java with -Xmx2500m.
We recently added 4 languages which made the total size of the artifacts increase from about 15Gb to about 20Gb. Before this increase, I have never encountered this issue.
I also have been trying to keep Jenkins up-to-date so I update regularly. That means that almost certainly, when we successfully built 15Gb of artifacts, we also ran an older version of jenkins. Also, at the time, the jenkins slave ran with the default heap size, a measily -Xmx250m. This suggests that this OOM issue may be a newly introduced.
Looking at the memory usage of java.exe on the slave, I see that it increases stepwise as it grabs another artifact to upload. At the moment, one third of the way through, it is up to 800mb peak usage.
Are you able to reproduce this behavior on a test instance? If so, could you share the full steps to reproduce?
Would also be interesting to learn whether this is a regression (I'm fairly sure it is), and in which release.
Would be good if you could compare behavior of Jenkins 1.626 and 1.627, as the latter contained a change related to archiving.
I wonder whether https://groups.google.com/d/msg/jenkinsci-users/M702ucKWUFI/vBhQs_npMAAJ could be related.
Upgrading to 64 bit java with -Xmx2500 did the trick for me.
I will see what I can do about trying this on 1.626-7 but I can't promise anything. The biggest issue is the node because it needs an InstallShield license to build this particular job. If I can hook that node up to a clone of my existing server, I should be able to test it. It will have to wait a week or two since we're in the middle of crunch time.
Another update here:
I am only able to run the job once, if I try it a second time, I will get OOM error. I have to restart the service on the slave to be able to run the build again.
We just got a new jenkins server. This one runs Windows Server 2012 R2. I copied the configuration from our old server and I hooked our existing build node up to this one.
I ran 1.626,7 and the latest version 2.6. Note that the reported build node version is 2.40 for all tests.
They all seem to consume about the same amount of memory when archiving artifacts, (about 1.3Gb).
An observation I made was that the nodes used a couple of hundred Mb before the archiving started and while archiving the memory usage slowly grew to the 1.3Gb cited above.
We are building suite installers for 14 languages, each of which is about 1Gb in size. Total size is 19Gb. While archiving these artifacts the note crashes with an OutOfMemoryError.
I've successfully worked around this issue previously by upping -Xmx to 1024m, from 256m)
The build log shows the following:
Digging into the logs on the slave I find this:
Originally reported by yngvedh, imported from: OutOfMemoryError when archiving large artifacts