Recommended hardware for big Crucible/Fisheye installation

Hi everyone,

our company is planning to get Crucible/Fisheye. We have some questions regarding the best suitable hardware setup in our situation:
- We expect 150+ Fisheye/Crucible Users
- We expect around 100 SVN repositories (not sure yet about wether we will add the repository roots to Crucible/Fisheye, or rather subfolders of the repositories - which would increase this number even more)
What hardware setup would you advise in our situation? We would like to have a setup which is ready for the years to come, since we will buy the hardware especially for this purpose (not using a vm).

Could you give us a hint on an optimal hardware setup with optimal performance?

Best regards,
Jan Becker

PS: I am aware of the answer to this question still i would like to get a more specific answer, since the answer simply seems to reproduce the (minimum?) requirements for Fisheye.

3 answers

1 accepted

1 vote
Answer accepted

It's not really big installation. Server with 3 GB of RAM and 2x2GHz CPU cores should be fine. If you want it for future, just buy server with quad core CPU and 16GB of RAM(RAM is cheap nowadays) and you will not need to worry for the next 3 years.

2 votes
Nick Pellow Atlassian Team Apr 08, 2014

In our own internal testing of various FishEye hardware, we've found huge improvements in performance when we use an SSD to store the FishEye cache data on. FishEye is more or less I/O bound, so I'd strongly recommend you get the fastest disk you can within your budget.

Since SSDs are prone to fail a little more often than regular HDDs, it would be recommended that you take nightly backups, that include your caches, to a separate disk. This is easily configured in FishEye.

The other constraint is definitely RAM - with more RAM, FishEye's caches can grow larger, and thereby need to hit your disk or db less. So AS Andris suggests, allocated 4GB or more to the JVM will help keep things humming.

Also - the more CPUs and the faster they are, the better performance you'll see. Again, try and get the fastest within your budget.

Nick, I apologize for hijacking this thread but:

It would be wonderful if the leak in caching code (that is guaranteed to cause OOM over time, with large enough number of repos) would finally go away.

Making the backups expire over time would be also good.

Thanks a lot for your quick replies, Andris and Nick, both answers are very helpful!

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Wednesday in Opsgenie

Getting the Most out of Atlassian and Opsgenie Together

We’re excited to invite you to this action-packed webinar where we will demonstrate how to integrate Opsgenie’s powerful alerting and on-call management tools with your entire Atlassian stack. Mar...

49 views 0 0
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you