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