Atlassian Crucible 在大型存储库上非常慢

Question

我的公司几个月来一直在试用 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 磁盘），但是当我们远离 VM 时，我们确实看到了轻微的性能提升。

Answer 1

由于迁移到 MySQL 对某些存储库产生了明显的影响，因此请考虑调整数据库以进一步改进。更改某些my.cnf默认值可能会产生巨大的差异。有关详细信息，请参阅InnoDB 性能优化基础知识。还可以通过启用慢查询日志来检查慢查询，并在适当的情况下添加索引。

我的下一个猜测是网络速度：您的 Crucible 实例是否与 SVN 存储库位于同一有线本地网络上？如果可能的话，您还可以尝试在主存储库所在的同一台计算机上试运行 Crucible，以消除网络延迟这一罪魁祸首。

我知道这可能会很困难，具体取决于您的工作环境，但在虚拟机中运行 Crucible 可能没有帮助；Atlassian 在其非常简短的Crucible 配置最佳实践页面上对此进行了记录。我相信您已经遇到过它，但我还将向其他读者提及调整 FishEye页面。

我还遇到大型项目的性能问题，但将速度缓慢归咎于 Crucible 繁重的 Web 界面。在单击一段时间后尤其如此（评论中以前查看过的页面仍保留在浏览器窗口中，即使隐藏在视线之外）。我们的开发人员注意到切换到 Google Chrome 后速度略有提高。另请检查Atlassian IDE Con​​nector是否存在适合您的开发环境的兼容插件。上次我使用 Eclipse IDE Con​​nector 时（很多个月前），它也有自己的问题，但它至少可以处理大型文件集而不会挂起。

根据您公司的开发实践，您可以停止扫描大量代码分支（假设其中许多代码分支不再活动），并禁用已完成/已死亡项目的存储库，直到需要它们为止。我的公司在大量项目上使用非常小的团队，因此大多数时间我们主要工作trunk，但分支机构除外；因此，我们明确添加要扫描的分支，而不是默认包含所有分支。还要确保您没有意外扫描标签。

Crucible 盒子上的 CPU 使用情况如何？如果您在 Apache HTTPD 后面使用 SVN，请检查 Crucible 在大型存储库扫描期间消耗了多少连接。除此之外，我不确定您还可以查看什么（也许是磁盘速度？存储库扫描频率？），但希望上述提示能有所帮助。