Recently we’ve been getting a lot of critical load notifications from contegix about our internal Bamboo build box for Jira. This is pretty much normal as we’ve got a lot of builds on Bamboo, and every check-in to subversion triggers a whole flood of different builds.
We did start to run out of physical memory on the box however, which is why we were looking at tuning the memory parameters of our test runners a little to stop our builds from swapping (thus affecting build times quite a bit…).
We were looking at reducing the heap-space for all the running Java processes (the Maven process, CargoTestRunner and so on), to stop the machine from swapping. When we were checking for any improvements we found that weeks ago (around the 12. April) completely unrelated to the memory tweaks we made in the past few days, build durations dropped roughly 20%:
With build number 407 build times dropped from 50 to 40 minutes (roughly). The commit message from that build speaks for itself:
This was a memory leak in webwork I fixed quite a while ago. I blogged about it here.
Without Bamboo’s nice stats we’d have never found however, that this little change to fix a memory leak also dropped our build durations this much (probably due to less overhead to do with garbage collection). Nice!
Shameless plug: Yes I’m shamelessly hyping Bamboo in this blog post. Why might I mention this you might ask? For one I’d like to prevent comments such as these (a futile battle perhaps), but mainly because there’s currently no other continuous integration server (that I know of anyway) out there that would have made me discover this improvement so easily!
