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

Modified on: Tue, 11 Jun 2019 09:40:02 +0800

我的公司已经对阿特拉斯坩埚进行了几个月的试验。对于工作正常的存储库,用户对该工具给出了非常积极的反馈。我遇到的问题是我们有几个不同的项目,每个项目都有自己的存储库,其中一些存储库非常大。特别是一个存储库具有大量分支,每个分支可能大约有9,000个文件。浏览Crucible中的存储库非常慢。

Crucible正在CentOS VM上运行。 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。硬件仍然适中(4GB RAM,四核CPU和带有外部备份的RAID 1中的双500GB磁盘),但是当我们离开VM时,我们确实看到了轻微的性能提升。

最佳答案

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

我的下一个猜测是网络速度:您的Crucible实例与SVN存储库位于同一个有线本地网络上吗?您也可以尝试在与主存储库相同的计算机上进行Crucible试运行,以消除网络延迟作为罪魁祸首。

我知道这可能很难取决于你的工作环境,但在VM中运行Crucible可能并没有帮助; Atlassian的做笔记的这对他们非常简短的坩埚的最佳实践配置页面。我相信你已经遇到过它,但我也会提到调整FishEye页面供其他读者使用。

我也有大型项目的性能问题,但归因于Crucible笨重的Web界面很慢。点击一下之后尤其如此(以前在浏览窗口中查看过的页面仍然保留在浏览器窗口中,即使是从视线中隐藏)。我们的开发人员注意到,切换到谷歌浏览器会略微提速。如果您的开发环境存在兼容的插件,请查看Atlassian IDE Con​​nector。 Eclipse IDE Con​​nector最后一次使用它时(几个月前)它有自己的问题,但它至少可以处理大型文件集而不会挂断。

根据您公司的开发实践,您可以停止扫描大量代码分支(假设其中许多代码分支不再处于活动状态),并禁用已完成/已停止项目的存储库,直到需要它们为止。我的公司在大量项目中使用非常小的团队,所以大部分时间我们主要在trunk上工作,使分支成为例外;因此,我们明确地添加分支以进行扫描,而不是默认包括所有分支。另外,请确保您不会意外扫描标签。

您在Crucible机箱上的CPU使用情况如何?如果您在Apache HTTPD后面使用SVN,请检查Crucible在大型存储库扫描期间消耗的连接数。除此之外,我不确定你还能看到什么(可能是磁盘速度?存储库扫描频率?),但希望上面的提示会有所帮助。

作者:Dave

相关问答

添加新评论