我的公司已经对Atlassian坩埚进行了几个月的试验。对于正常运行的存储库，用户对该工具给出了非常积极的反馈。我遇到的问题是我们有几个不同的项目，每个项目都有自己的存储库，其中一些存储库非常大。特别地，一个存储库具有大量分支，每个分支大概有9,000个文件。在Crucible中浏览该存储库非常慢。
Crucible在CentOS VM上运行。该虚拟机具有4GB的RAM，我将Crucible的最大值设置为3GB，其中当前正在使用2GB。我已经在Atlassian的支持通知单中提出了这个问题，他们提出了以下建议：
特别是因为您有一个相当大的SVN存储库，您可能会发现Fisheye将在磁盘上创建一个大型索引文件。为了帮助提高性能，您可以尝试以下操作：
- 增加Fisheye可用的可用内存。
- 迁移到外部数据库。
- 从索引中排除不需要的文件和目录。
我已经在某种程度上尝试了所有这些方法，但是到目前为止，都没有太大的帮助。我最初使用内置的HSQL DB在具有2GB RAM的Windows机器上运行Crucible。在CentOS上迁移到MySQL可以看到某些存储库的性能提高，并使Crucible更加稳定，但是对于我们最大的存储库似乎并没有太大帮助。在保持工具有用性的同时，我可以从索引中排除的文件/分支如此之多。
既然如此，有没有人有任何关于如何在大型存储库上加速Crucible的提示，而无需投资于功能强大的硬件？
谢谢！
编辑：澄清一下，因为我上面没有明确提到，所以我使用的是FishEye。
编辑2：自从我最初发布此内容以来，新的Crucible版本的性能有所改善，但是无论如何仍然不是很好。看来此问题影响了许多用户，包括一些硬件功能比我们使用的功能强大得多的用户。因此，我不认为这是硬件问题，而是坩埚内在效率低下的问题。Atlassian意识到了这个问题，并将在未来的发行版中包括进一步的性能改进，因此希望这些更改能够解决我们的问题。
编辑3：我忘记了多久以前问这个问题，所以在我以前的编辑中，我没有提到自从最初提出要求以来，我们的硬件情况也发生了变化。我们现在仍在使用CentOS在专用的物理服务器上运行Crucible。硬件仍然很少（RAID 1中有4GB RAM，四核CPU和双500GB磁盘以及外部备份），但是当我们离开虚拟机时，确实看到了稍微的性能提升。