我的公司已经试用 Atlassian Crucible 几个月了。对于运行正常的存储库，用户对该工具的反馈非常积极。我遇到的问题是，我们有几个不同的项目，每个项目都有自己的存储库，其中一些存储库非常大。特别是一个存储库有大量分支，每个分支大约有 9,000 个文件。在 Crucible 中浏览该存储库非常慢。
Crucible 在 CentOS VM 上运行。VM 有 4GB 的 RAM，我将 Crucible 的最大内存设置为 3GB，目前它使用了 2GB。我在 Atlassian 的支持单中提到了这个问题，他们提出了以下建议：
特别是因为您有一个相当大的 SVN 存储库，您可能会发现 Fisheye 将在磁盘上创建一个大型索引文件。为了帮助提高性能，您可以尝试以下几件事：
- 增加鱼眼的可用内存。
- 迁移到外部数据库。
- 从索引中排除不需要的文件和目录。
我尝试了所有这些方法，但到目前为止，它们都没有太大帮助。我最初在一台拥有 2GB RAM 的 Windows 机器上运行 Crucible，使用内置的 HSQL DB。迁移到 CentOS 上的 MySQL 后，一些存储库的性能得到了提升，Crucible 也变得更加稳定，但似乎对我们最大的存储库没有太大帮助。在保持工具实用性的同时，我只能从索引中排除这么多文件/分支。
既然如此，有没有人能提供一些关于如何在大型存储库中加速 Crucible 的技巧，而无需投资于功能强大的硬件？
谢谢！
编辑：需要澄清的是，由于我上面没有明确提到，我是使用鱼眼。
编辑2：自从我最初发布这篇文章以来，新版 Crucible 的性能有所改善，但仍然不是很好。似乎这个问题影响很多用户，包括一些比我们使用的硬件更强大的硬件。因此，我认为这不是硬件问题，而是 Crucible 固有效率低下的问题。Atlassian 意识到了这个问题，并将在未来版本中进一步提高性能，所以希望这些变化能解决我们的问题。
编辑3：我忘记了多久前问过这个问题，所以在之前的编辑中我忘了提到我们的硬件情况自最初提出以来也发生了变化。我们现在在专用的物理服务器上运行 Crucible，仍然使用 CentOS。硬件仍然很普通（4GB RAM、四核 CPU 和双 500GB 磁盘，RAID 1，外部备份），但当我们离开虚拟机时，我们确实看到了性能的轻微提升。
答案1
由于迁移到 MySQL 对某些存储库产生了明显的影响，请考虑调整数据库以进一步改进。更改某些my.cnf默认值可能会产生巨大的影响。请参阅InnoDB性能优化基础了解更多信息。还可以通过启用慢查询日志并在适当的地方添加索引。
我的下一个猜测是网络速度：您的 Crucible 实例是否与您的 SVN 存储库位于同一个有线本地网络上？如果可能的话，您还可以尝试在与您的主存储库相同的机器上试运行 Crucible，以消除网络延迟作为罪魁祸首。
我知道这可能很难，具体取决于你的工作环境，但在虚拟机中运行 Crucible 可能无济于事；Atlassian 在他们的简短坩埚配置的最佳实践页面。我相信你已经看过了，但我还要提一下调整鱼眼其他读者的页面。
我在大型项目中也遇到了性能问题，但我认为大部分缓慢的原因在于 Crucible 繁重的 Web 界面。点击几下之后尤其如此（评论中之前查看的页面会保留在浏览器窗口中，即使隐藏起来也不受影响）。我们的开发人员发现，切换到 Google Chrome 后速度略有提升。另请查看Atlassian IDE 连接器是否存在适用于您的开发环境的兼容插件。上次我使用 Eclipse IDE Connector 时（几个月前），它本身也存在问题，但它至少可以处理大型文件集而不会挂断。
根据贵公司的开发实践，您可以停止扫描大量代码分支（假设其中许多分支不再活跃），并禁用已完成/已终止项目的存储库，直到需要它们为止。我的公司在大量项目上使用了非常小的团队，因此大多数时候我们主要在 上工作trunk，分支是例外；因此，我们明确添加要扫描的分支，而不是默认包含所有分支。还要确保您不会意外扫描标签。
Crucible 盒子的 CPU 使用率如何？如果您在 Apache HTTPD 后面使用 SVN，请检查 Crucible 在大型存储库扫描期间消耗了多少连接。除此之外，我不确定您还能查看什么（可能是磁盘速度？存储库扫描频率？），但希望上述提示能有所帮助。
答案2
>4G RAM 并不是“非常强大”的硬件。假设您有 25 个用户，并且您正在使用 Fisheye（您提到过），那么您仅在软件上就花费了 4400 美元。戴尔的 4000 美元可以为您购买一台具有 48G RAM 的服务器。
另外，您使用的是 64 位 JVM 吗？文档建议您在 32 位 JVM 上看到更好的内存占用（即更少的内存）。
答案3
虽然我自己并没有真正尝试过，但我遇到的症状和你完全相同。
我目前正在考虑关闭有问题的存储库的存储差异信息。我问了这个问题Atlassian 的问答网站并得到了一些有希望的建议。
我的问题是一样的——索引不是问题，而是在虚拟机中性能不佳的磁盘阵列上运行的巨大磁盘占用。由于我目前无法升级磁盘，所以我需要找到另一种解决方法。我上面帖子中的回答者说，删除 diff 信息将减少磁盘占用以......为代价失去搜索添加/删除的行的能力。不过他也表示这不会影响浏览历史较长的文件的速度。
如果其他人看到此消息并能报告此开关的成功/失败，请在此处发表评论。
哦，我正在运行 2.7.13，遇到了同样的性能问题。