我的公司几个月来一直在试用Atlassian Crucible。 对于正常工作的存储库，用户对该工具给予了非常积极的反馈。 我遇到的问题是我们有几个不同的项目，每个项目都有自己的存储库，其中一些存储库非常大。 一个存储库特别是有大量的分支机构，每个分支大概有9000个文件。 在Crucible中浏览该存储库非常缓慢。
坩埚在CentOS虚拟机上运行。 虚拟机有4GB的内存，我已经把Crucible的最大容量设置为3GB，目前它的容量是2GB。 我把它和Atlassian一起提交给了支持者，他们提出了以下build议：
特别是因为你有一个相当大的SVN仓库，你可能会发现Fisheye将在磁盘上创build一个大的索引文件。 为了帮助提高性能，您可以尝试一些操作：
- 增加鱼眼可用内存。
- 迁移到外部数据库 。
- 从索引中排除不需要的文件和目录 。
我已经尝试了所有这些东西，但迄今为止没有任何帮助。 我最初使用内置的HSQL数据库在2GB RAM的Windows机器上运行Crucible。 在CentOS上转移到MySQL看到了一些版本库的性能提升，使Crucible变得更加稳定，但对于我们最大的版本库似乎并没有多大帮助。 只有很多文件/分支可以从索引中排除，同时保持工具的有用性。
既然如此，有没有人有任何提示，如何加快Crucible大型仓库，而不投资在疯狂强大的硬件？
谢谢！
编辑：澄清，因为我没有明确提到它上面，我使用FishEye。
编辑2：由于我最初发布这个，新的Crucible发行版本的性能有所提高，但它仍然不是很好。 看起来这个问题影响了很多用户 ，包括一些比我们使用的function更强大的硬件。 因此，我不认为这是一个硬件问题，而是一个在Crucible中固有的低效率问题。 Atlassian意识到这个问题，并将在未来版本中进一步提高性能，希望这些变化能够解决我们的问题。
编辑3：我忘记了多久以前我问过这个问题了，所以在我之前的编辑中，我忽略了提到我们的硬件情况自从最初被问到以后也改变了。 我们现在在专用的物理服务器上运行Crucible，仍然使用CentOS。 硬件仍然是适度的（4GB内存，四核CPU和RAID 1中的双500GB硬盘，外部备份），但是当我们离开虚拟机时，性能有所增长。
由于迁移到MySQL对于某些存储库有明显的不同，请考虑调整数据库以进一步改进。 从默认值更改一些my.cnf值可以有很大的不同。 有关更多信息，请参阅InnoDB性能优化基础知识 。 还可以通过启用慢查询日志并在适当的地方添加索引来检查速度较慢的查询 。
我的下一个猜测将会是networking速度：您的Crucible实例是否与您的SVN存储库位于相同的有线本地networking上？ 如果可能的话，你也可以尝试给Crucible在同一台机器上作为主存储库的试用版，以消除networking延迟的罪魁祸首。
而且我知道这取决于你的工作环境可能很困难，但是在虚拟机上运行Crucible可能不会有帮助; Atlassian在其非常简短的“坩埚configuration最佳实践”页面中记下了这一点。 我相信你已经遇到过，但我也会提到其他读者的调音FishEye页面。
我也有大型项目的性能问题，但归因于Crucible沉重的Web界面的缓慢。 在点击一下之后，尤其如此（浏览器窗口中以前浏览过的页面仍保留在浏览器窗口中，即使隐藏不见也是如此）。 我们的开发人员已经注意到，切换到谷歌浏览器的速度略有提高 如果您的开发环境中存在兼容的插件，请查看Atlassian IDE Connector 。 Eclipse IDE Connector最后一次使用它（几个月前）时有问题，但它至less可以处理大型文件集而不挂断。
根据您公司的开发实践，您可以停止扫描大量代码分支（假设其中的许多代码分支不再处于活动状态），并且在需要时禁用已完成/已死项目的存储库。 我公司在大量项目中使用非常小的团队，所以大部分时间我们主要在trunk上工作，使分支成为例外; 因此我们明确地添加分支来扫描，而不是默认包含所有分支。 还要确保你不是不小心扫描标签。
Crucible框中的CPU使用情况如何？ 如果您在Apache HTTPD后面使用SVN，请检查在大型资源库扫描期间Crucible消耗的连接数。 除此之外，我不确定你还能看到什么（也许磁盘速度？存储库扫描频率？），但希望上面的提示会有所帮助。
> 4 G的RAM不是“疯狂强大”的硬件。 假设你有25个用户，而且你正在使用Fisheye（你提到的），那么你的软件只花费了4400美元。 戴尔4千美元可以为您购买带有48G内存的服务器。
另外，你使用的是64位的JVM吗？ 该文档build议您在32位JVM上看到更好的内存占用（如，更less）。
虽然我自己并没有真正尝试过，但我正在经历和你一样的症状。
我目前正在考虑closures违规存储库的存储差异信息。 我问Atlassian问答网站的问题，并得到了一些有希望的build议。
我的问题是一样的 – 索引是不是问题，这是一个巨大的磁盘空间运行在一个虚拟机的性能不佳的磁盘arrays。 由于目前我无法升级磁盘，所以我需要另辟蹊径。 上面我的post中的回答者说，删除差异信息将减less磁盘占用量 ，但是会失去search添加/删除行的能力 。 尽pipe他也表示，它不会影响浏览历史悠久的文件的速度。
如果其他人看到这个＆可以通过这个开关报告成功/失败，请在这里留言。
哦，我运行2.7.13具有相同的性能问题。