can anyone tell me what is the ideal hardware requirement for Bamboo 4.0 or 4.4 it should be in a position to support 1000+ plans
jdk 1.7, 1.6 jrockit etc
maven 2, 3 etc
Clarecase 7.1 repository
10 local agents
right now we are runing bamboo 2.7 on x86, 64 bit, winodws nt, 6 gb ram etc... but with this configuration i am seeing bamboo service is getting slower day by day and now we thought of upgrading it to newer version and better hardware.
You would deiniftely see a performance improvement (and lots of new features) by upgrading to the newest Bamboo version. With 1000+ plans the biggest problem is you have 10 local agents and only 6 GB of RAM. How many CPU cores do you have allocated? A typical assignment it to have at least 1 (preferably 2) cores for Bamboo server and 1 core for each local agent. With 1000+ plans I have to imagine all 10 local agents are typically busy throughout the day?
If you have 1000+ plans I would seriously recommend using Remote Agents on other VMs or hardware to get the local agent processing off the Bamboo server. That is most likely killing your Bamboo server performance, especially with that many plans.
For comparison... I previously operated a Bamboo server with roughly 600+ plans and 500+ users on x86, 64-bit Linux VM with 8 GB RAM and 4 CPU cores (at ~2 Ghz) operating 40+ remote agents on seperate VMs and the overall system performance was fiarly good.
However, a lot depends on how frequently your plans execute (single dailies, manuals, or hourlies)? If you have a lot of scheduled plans try to stagger them a bit more or schedule them for times when load is low.
Additionally, not sure if Clearcase allows a Quiet period, but I use Subversion repos a lot and in the Bamboo Plan config for the repo I can specify a Quiet Period. A Quiet period allows you to delay building after a single commit is detected, aggregating multiple commits per build. For active development projects if Developers commit very frequently and the Bamboo Plan is set to poll the repo for changes then a lot of unnecessary builds can get kicked off by multiple developer commits. I recommend a quiet period of 10 minutes, but everyone has different needs.
Another factor that will affect your performance is the Artifacts. If your build plans have lots of Artifacts defined and created this will add load to the network and a little to the server (when using Remote Agents not local agents) as a defined artifact gets transferred back to the Bamboo server from the remote agent so it is available for download and to other Jobs if the artifact is shared.
Finally, for 1000+ plans you should enable a very aggrsive build expiration policy. I recommend all build results get expires (deleted) after 30 days unless a build team flagged it with a special label. System performance can definitely suffer with 1000+ plans over time if you don't clean up.
Your Bamboo server storage space heavily depends on your usage pattern, i.e. how many plans you will have, how many tests each plan will be executing (i.e. how large your test results are going to be), how many artifacts you are going to have and how large they are. We have Bamboo instances that get away with using 100MB on top of the installed size and ones that go up to 1TB. The best thing to do is allocate the recommended 20GB on top of the installed size, and see how much you will need on top if your usage will grow.
As for the processor, it again heavily depends on the load of the work that will be processed, my best recommendation will be going with a dual, and keep an eye on it to determine whether you need more processor power or not.
For the remote agents, if you are running them on a remote machine (machines) it will put less pressure on the Bamboo server. Running them on the same machine is possible but will need more CPU power and disk space depending on the complexity of you plans and the number of artifacts you will have.
I hope this information is helpful.
Can you believe there's less than one month until Summit 2019? It's time to start planning your agendas, not to mention packing ... In the meantime, introduce yourselves on this thread so that you ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs